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ABSTHACT 


References  submitted,  annotated,  and  lated  by  students 
in  a  course  on  Computer  Program  Engineering  are  organized  by 
topic  and  by  average  rating,  with  cross-references  and  an 
author  index.  This  report  updates  and  supercedes  CSRG-24. 
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PREFACE 


This  bibliography  is  an  outgrowth  of  a  gr 
on  Computer  Program  Engineering  (CS2105)  tau 
W.M,  McKeeman  and  in  both  1972  and  1973  by  J 
In  each  year,  students  were  asked  to  read  wid 
references  in  a  standard  form,  and  to  aim 
entries  in  the  bibliography.  In  the  past  t 
student  was  also  required  to  rate  each  item 
basis  of  relevance  to  the  course.  These  su 
then  screened,  collated,  sorted,  summarized,  a 
placed  in  their  current  format  by  the  editor. 

Both  the  annotations  and  ratings  are  base 
to  Computer  Program  Engineering,  as  taught  in 
the  University  of  Toronto,  and  should  not 
absolute  judgements  on  the  cited  items.  Th 
and  editor  have  also  exercised  their  judgement 
items  which  they  deemed  irrelevant  to  th 
coarse.  Thus,  this  bibliography  should  be 
context  of  the  following  definition: 

Computer  Program  Engineering  is  a  d 
directed  to  the  production  of  computer 
that  are  correct,  efficient, 
maintainable,  and  understandable,  in  r 
time  spans,  at  acceptable  costs. 
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Weinberg? 1 


CH23,001 


31*  18 


Weinberg,  G.M.;  The  Psychology  of  Computer  PrograjP  ming; 
Van  Nostrand  (1971)  pp. 1-288. 

This  book  is  unique  in  that  it  discusses  the  art 
and  science  of  computer  programming  not  from  the 
viewpoint  of  the  machines  and  programs  which  are 
generally  thought  of  as  its  main  subject  matter,  but 
from  the  human  factors  viewpoint.  The  author  discusses 
the  factors  in  a  programmer's  psychological  makeup 


which  affect  his 

programs. 

and  the 

ways 

in 

which 

programs  vary 

according 

to  the 

person 

ality 

and 

emotional  outlook 

of  their  cr 

eators. 

Program 

ming 

team 

environments  are 

looked  at 

from  the 

point 

of  vi 

ew  of 

the  individual  programmer.  The  effect  of  both  his 
formal  and  informal  connections  within  (and  without) 
the  team  on  his  productivity  and  programming  style  is 
considered . 

Suggestions  are  made  for  improvements  in  the 
fields  of  programming  language  design,  education  of 
programmers,  programming  aptitude  tests^,  project 
structure,  and  many  others  based  on  empirical 
psychological  data  and  studies  of  human  beings  and 
their  characteristics. 

The  author  expresses  some  of  the  spirit  of  the 
book  in  his  concluding  remarks,  when  he  expresses  the 
hope  that  the  knowledge  of  human  factors  involved  in 
the  programming  task  and  systems  in  general  presented 
in  the  book  will  be  of  use  to  the  reader  in  his  own 
office,  project,  class,  or  other  programming 
environment. 


Naur6  9  b 


14*18 


Naur,  P.,  and  fiandell,  E.  (ed,);  Software  Engineering; 
NATO  Scientific  Affairs  Division,  Brussels,  Belgium 
(1969)  pp. 1-231. 

Bauer72  CH25,047  3*18 

Bauer,  F.L.;  Software  Engineering;  Proceedings  of  IFIP 
Congress  71,  vol.  1  (1972)  pp. 530-538. 

A  definition  of  the  term  "software  engineering"  is 
given  as  "the  part  of  computer  science  which  j.s  too 
difficult  for  the  computer  scientist".  The  aims  of 
software  engineering  are  discussed,  along  with  reasons 
for  adopting  these  aims,  and  the  problems  involved  in 
meeting  them.  The  role  of  education  in  the 
introduction  of  software  engineering  techniques  to  the 


2 


progLaioming  cofflinunity  is  mentioned,  and  the  resultant 
obsolesence  of  present  programming  techniques  is 
predicted.  Problems  involved  in  applying  techniques  of 
industrial  engineering  to  software  are  explored,  and 
solutions  for  some  are  offered.  The  role  of  structured 
programming  as  a  tool  for  application  of  those 
techniques  is  investigated  at  some  length,  and  some 
problems  not  solved  by  this  tool  are  examined.  The 
concluding  remarks  present  some  ramifications  of  the 
techniques  and  philosophy  of  software  engineering  for 
the  programming  community,  and  point  out  the  need  for 
comparative  testing  and  more  widespread  discussion  and 
use  of  these  points  in  order  to  achieve  progress  in  the 
f ield . 

Bauer 7 3 

Bauer,  F.L,;  Software  and  Software  Engineering;  SIAM 
Review,  vol.15,  no. 2  part  2  (April  1973)  pp. 469-480. 

This  is  a  survey  paper  on  software  engineering. 
It  is  discussed  under  the  following  four  headings:  (1) 
how  the  term  ’’software"  developed;  (2)  how  software  was 
(and  still  is)  developed;  (3)  how  software  should  be 
developed;  (4)  how  software  engineering  should  develop 
in  the  future.  Under  (1)  and  (2)  a  brief  history  of 
software  and  its  relation  to  computing  is  given  all  the 
way  back  to  Babbage.  Under  (3)  the  software  crisis  is 
analysed  and  suggestions  for  its  mastery  are  given, 
finally  under  (4)  the  problems  of  educating  the  next 


generation  of 

programmers  is  discussed. 

Buxton7 1 

4*  17 

Buxton ,  J. N. ; 

The 

Nature  and  Implications 

of  Software 

Engineering ; 

in 

Hugo,  J. S,  (ed) , 

The  Fourth 

Infotech,  Ltd.,  Berkshire,  England  (197  1) 

pp. 227-238. 

In  this  paper,,  Buxton  attempts  to  make  clear  what 
software  engineering  is,  by  first  trying  to  define 
computer  science,  and  then  by  explaining  how  software 
engineering  differs  from  it.  Secondly,  he  discusses 
the  essential  nature  of  software  engineering. 

Buxton70  3*17 

Buxton,  J.N.,  and  Randall,  D.  (ed.);  Software 
Engineering  Techniques;  NATO  Scientiric  Affairs 
Division,  Brussels,  Belgium  (1970)  pp. 1-164. 

Turski70  5*12 

Turski,  W.  (ed.);  The  Efficient  Production  of  Large 
Programs;  Polish  Academy  of  Sciences  (1970)  pp. 1-130. 


3 


fosdick?  2 


1 1 


Fosdick,  L.D, ;  The  Prod 
Softwdre;  Communication 
1972)  pp. 611-617. 
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Riddle72 

Riddle,  W.E,;  An  Annot 
Architecture;  Stanfor 
Computation  Group,  no. 


action  of  Better  Mathematical 
s  of  the  ACM,  vol.15,  no. 7  (July 


number  of  suggestions  are  made 
the  area  of  software  production, 
ly  oriented  towards  the  problem 
mathematical  software,  it  is  not 
on  any  peculiarities  of  this 
The  suggestions  are  divided  into 
validation,  documentation  and 
out  the  strong  coupling  between 
tely  ignores  the  questions  of 
mechanics  of  the  production  of 
eated  in  Mills  and  Baker. 

ven  and  perhaps  too  shallow  in 
problems  in  the  areas  discussed. 
It  suggests  in  simple  terms  the 
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very  interesting  idea  emerges 
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d  Linear  Accelerator  Center, 
138  (September  1972)  pp.  1-103. 
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I  ndijemen  t 

Michaelson68  CU16,412  1*18 

Michaelsoii,  S.;  How  to  Succeed  in  Software;  Proceedings 
of  the  IFIP  Congress  19t)H,  vol.  1  (1968)  pp.  330-33'i. 

This  is  short,  very  enjoyable  paper  on  software 
problems.  Since  it  was  written  in  the  days  when 
software  was  just  pecoining  a  critical  area  for  concern, 
it  lacks  the  detail  ot  later  papers.  However,  it  is 
eminently  suit«?d  tor  giving  a  concise  view  of  what  the 
software  problem  really  is  and  demonstrates  remarkable 
forsight  in  sonu'  suggeiitions  keep  good 
programers  programnii  ikj  instf'ad  ot  managijig).  Finally, 
a  list  of  seven  items  tor  software  s.uccess  is  given. 

Baker72a  Cl<2  1,  1  1  3  20*  16 

baker,  F.T.;  Chief  Programmer  Team  M  anageiuen  t  of 
Production  Programming;  IBM  Systems  Journal,  vol,  11, 
no.  1  (1972)  pp„b6-73. 

Baker  describes,  in  detail,  the  organization  and 
operation  of  a  chief  programmer  team  involved  in  a 
particular  task:  the  programming  of  the  N.  Y.  Times 
information  bank  syst(?m.  The  chief  programmer  team 
represents  an  integration  of  previously  known 
programming  management  technigues  that  have  been 
individually  tried  in  the  past.  If  they  are  applied  in 
a  constant  manner  over  an  entire  project,  they  work 
together  well. 

Mills71a  13*16 

Mills,  Chief  Programmer  Teams:  Principles  and 
Procedures;  IBM  Federal  Systems  Division,  no. FSC7 1 -5 1 08 
(June  197  1)  „ 

Smith72b  Ck23,741  1*16 

Smith,  D.;  An  Organization  tor  Successful  Project 
Management;  Proceedings  of  the  SJCC,  vol. 40  (May  1972) 
pp.  129-140. 

Describes  some  of  the  major  problecES  in  software 
development  including  those  associated  with 
unsatisfactory  products,  schedule  delays  and  excessive 
costs.  Gives  a  good  top-down  project  management  design 
which  presents  most  of  the  major  ideas  in  gc^netal 
project  management,  but  is  overly  general  depending  too 
much  on  intuitive  ideas. 
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Evans , 
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D.  J . 

(e 

(1970) 
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The  Current  Software  Situation;  In  Evans, 

•)  '*  Software _ 70^  Transcripta  Books,  London 

19-29. 
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Int.  C 


imputersTO 


1*15 


Inrer national  Computers  Ltd. ;  Programming  Procedures,  A 
profesional  Approach  to  the  Planning  and  Control  of 
Programming;  International  Computers  Ltd.,  London, 
England,  no. 4202  (1970)  pp. 1-250. 

This  manual  includes  sections  on  project 
organization,  project  design,  program  design,  resource 
planning,  programming,  and  documentation.  Appendices 
are  included  which  contain  examples  of  real  working 
documents,  and  actual  standards  for  common  larguacas 
(e.g.,  COBOL).  The  book  also  touches  on  personnel 
allocation.  Of  particular  interest  is  the  section  on 
modular  programming,  demonstrating  ICL’s  real-world 
approach  to  a  theoretical  problem. 


Wolf e69 


1*15 


Wolfe,  J.H.;  Testing  for 
Datamation,  vol,15,  no. 4  (April 


Schwar tz70 


Programming  Aptitude; 
1969)  pp. 67-72. 

6*14 


Schwartz,  J.D,;  Analyzing 
Development;  in  Buxton,  J.N. 
Software  Engineering  Techniques 
137, 
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)r  has  been  involved  in  the  design  and 
a  number  of  large-scale  programming 
first  describes  some  experiences  with 
systems,  then  outlines  in  detail  the 
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ptobleias  associated  with  large-scale  system  development 
and  offers  some  recommendations  for  dealing  with  these 
problems^  and  concludes  that  large-scale  system 
development  is  a  "people"  problem. 


A vots7  3 


2*14 


Avots,  J. ;  Making  Project  Management  Work: 
vol.19y  no.1  (January  1973)  pp. 42-45. 


Datamation , 


Discusses  the  human  and  technical  factors 
(emphasizing  the  former)  that  contribute  to  the  success 
of  a  large  systems  project.  Many  management  tools  for 
project  scheduling  and  reporting  are  available  or  may 
be  developed.  For  large  projects  they  will  be 
computer-based.  However  participation  in  planning  and 
a  common  understanding  of  procedures  and  goals  by  all 
project  members  is  essential  in  order  to  sustain  the 
necessary  enthusiasm  and  co-operation. 


Fient  7  3 


1*14 


Fient  j,  H.G.;  Management  of  the  Acquisition  Process  for 
Software  Products;  Management  Informatics,  vol.2,  no. 3 
(June  1973)  pp. 153-164. 

A  discussion  of  software  brokerage  as  a  possible 
solution  to  the  increasing  cost  of  software  development 
and  the  rising  tendency  to  buy,  rather  than  develop, 
application  software  with  the  consequent 
dissatisfaction  resulting  from  lack  of  standards  and 
control.  The  article  gives  the  pros  and  cons  of 
writing  one's  own  software  and  an  overview  of  the 
software  product  market  giving  sources  of  supply  and 
information  and  listing  typical  user  and  supplier 
complaints.  A  detailed  breakdown  of  the  requirements 
typically  encountered  is  given  covering  costs,  design, 
ease  of  use,  maintenance,  testing,  documentation  and 
contracting.  Finally  a  description  of  software 
brokerage  detailing  services  provided  to  user  and 
supplier  is  given. 


Halst ead73 


2*13 


Halstead,  M.H. 
Proceedings  of 


Language  Selection 
e  SJCC,  vol.42  (Jui 


for  Applications; 
le  1973)  pp. 211-214. 


The  author  outlines  guidelines  for  selecting  a  new 
language  for  a  given  application.  Four  important 
considerations  which  should  be  recognized  when  making 
such  decisions  are: 

1.  How  a  programmer  spends  his  time 

2.  Differences  in  local  and  global  inefficiency 

3.  The  role  of  the  expansion  ratio 

4.  Variance  in  programmer  productivity 
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Simmons?  2 


2=*^  13 


Simmons,  D.B.;  The  Art  of  Writing  Large  Programs; 
Computer,  vol.5,  no«2  (March/April  1972)  pp. 43-49. 

This  article  is  oriented  towards  alleviating 
problems  one  encounters  when  writing  large  programs  and 
improving  programmer  productivity.  First,  many  factors 
such  as  poor  communications  and  programmer  turnover  are 
discussed  as  problem  areas  in  writing  large  programs. 
Then  techniques  for  improving  programmer  productivity 
are  discussed,  with  emphasis  on  improving 
communications  between  programmers  and  managers,  users, 
and  the  general  environment.  The  areas  dealt  with  are 
programmer  task  assignment  and  supervision,  programmer 
environment,  programming  techniques,  and  program 
documentation.  Although  a  brief  treatment  of  all  these 
topics  is  given,  the  author  seems  to  touch  on  most 
major  areas  of  concern  and  offers  practical  advice  as 
to  how  to  write  large  programs. 


Berner  69 


11*12 


Berner,  H.W. 
Production ; 
Engineering 


Checklist  for  Planning 
in  Naur,  P. ,  and  Randell, 
(1969)  pp. 165-180. 
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Haney72  C825,504  3*12 

nancy,  F. N. ;  Module  Connection  Analysis  -  A  Tool  for 
Scheduling  Software  Debugging  Activities;  Proceedings 
of  the  FJCC,  vol.41  (1972)  pp. 173-179. 

Presents  a  laethod  for  estimating  the  amount  of 
work  necessary  to  make  changes  to  a  large  system,  or  to 
complete  the  final  testing  and  integration  of  such  a 
system.  For  a  system  composed  of  M  modules,  the  method 
examines  an  n*n  matrix  of  estimated  probabilities,  the 
(i,j)th  element  being  the  probability  that  a  change  in 
the  ith  module  will  require  a  change  in  the  jth  module. 
Knowing  this  matrix  and  knowing  the  number  of  initial 
(’’first  order”)  changes  (usually  corrections  of  bugs) 
that  a  system  requires,  one  can  then  easily  compute  how 
rapidly  the  system  converges  to  one  where  the  desired 
changes  have  been  made  and  no  undesired  changes 
introduced,  and  whether  this  process  can  be  expected  to 
converge  at  all.  The  method  is  applied  in  evaluating  a 
strategy  for  releasing  new  versions  of  a  specific 
example  system. 

Kay69  CR17,794  2*12 

Kay,  a.H.;  The  Management  and  Organization  of  Large 
Software  Development  Projects;  Proceedings  of  the  SJCC, 
vol.34  (1969) pp. 425-433. 

This  paper  discusses  common  management  problems, 
presenting  solutions  to  some  major  problems  and 
specifying  unresolved  areas.  Some  important  key  words 
are:  real  world,  human  aspects,  system  specifications. 


documentation,  project  plan,  evaluation. 

Bemer70  CH21,123  1*12 

Berner, K.W.;  Manageable  Software  Fngineering;  in  Tou, 

J.T.  (ed.).  Software _ Enailieer  ingj^^  vol,  1  (1970) 

pp,  121-137. 

McMonigall70  3*11 


McMonigall,  J.P,;  Criteria  for  the  Design  and 
Implementation  of  Application  Packages  for  Third  - 
Generation  Computers;  in  Evans,  D.J.  (ed.).  Software 
70^  Transcripta,  Ltd.,  London  (1970)  pp. 92-97. 

McMonigall  is  associated  with  a  software  house 
that  provides  application  packaoss  to  its  own  service 
bureau  as  well  as  to  customers,  f  -.e  his  experience  in 
applications  package  design,  he  breaks  the  process  into 
seven  phases:  pre-design,  market  research,  initial  cost 
estimation,  design  and  evaluation  of  the  technical 
system,  post-design,  implementation,  and  systems 
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review.  The  article  gives  an  overall  view  ot 
applications  package  design  and  advocates  starting  from 
scratch  design  as  opposed  to  "packageising”  an  existing 
system. 


Tsichri tzis73 


4^  10 


Tsichritzis,  D. ;  Project  Management;  in  Bauer,  F.L. 
(ed.).  Advanced  Course  in  Software  Engineering, 
Springer- Verlag,  New  York  (1973)  pp. 374-384. 


Cosgr ove7 1 


2*10 


Cosgrove,  J. ;  Needed  Now:  New  Planning  Framework; 
Datamation,  vol.  17,  no.  23  (December  1971)  pp. 37-39. 

The  author  describes  the  problems  of  programming 
management.  He  discusses  what  is  wrong  with  the 
traditional  way  of  handling  programmers,  and  how  they 
should  be  dealt  with  in  this  time  of  increasingly  more 
complex  problems. 


Master s68 


Masters,  P.R.;  Evalu< 
Australian  Computer 
1968)  pp, 124-129. 
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The 


for 


to  program  size)  and  proposes  several  means  of 
measuring  the  performance  of  programmers  in  order  to 
control  the  cost  and  effectiveness  of  the  programs  they 
produce.  These  measures  include  factors  such  as 
program  reliability,  how  long  it  took  to  write  the 
program  (both  calendar  time  and  man  hours) ,  running 
efficiency,  and  ease  of  modification.  A  reporting 
procedure  is  suggested  so  that,  at  all  times, 
management  knows  the  status  of  different  programs. 


Jackson7  0 


CR19,524 


Jackson,  B.J.;  Evaluating 
Australian  Computer  Journal, 
1970)  pp. 22-26. 


Programmer 
vol, 2 ,  no, 1 


1*10 

Workload ; 
(February 
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In 

order 

for 

a  supervisor  of 

a 

programming 

team  to  be  able  to  allocate  his  programmers  to  the 
problem,  he  roust  know  the  number  of  programmers  in  the 
team,  the  proportion  of  time  each  spends  programming. 
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the  classification  of  all  programroers  by  grade  of 
experience  and  skill,  the  nuater  of  programs  to  be 
written  classed  by  complexity,  an  estimated  time  to 
write  these  and  the  relationship  between  each  grade  of 
programmer  and  their  programming  output.  From  these, 
the  author  develops  a  Programmer  Base  Workload  Table 
and  uses  it  to  develop  a  Programmer  Workload  Allocation 
Matrix,  from  which  job  allocations  are  made. 

Trapnell69  Cxi17,B22  1*10 

Trapnell,  F.M.;  A  Systematic  Approach  to  the 
Development  of  System  Programs;  Proceedings  of  the 
SJCC,  vol.  34  (1969)  pp. 411-418. 

WrightoS  CH16,114  1*10 

Wright,  A.H.;  The  Management  of  Applications 
Programming;  Proceedings  of  IFIP  Congress  68  (Aug. 
1968)  pp. 414-419. 

Discusses  applications  programming  only,  although 
the  author  feels  that  similar  problems  and  solutions 
may  exist  in  other  areas  The  paper  consists  of  36 
numbered  topics  and  a  flowchart  showing  the  training, 
education,  and  career  patterns  for  programmers.  The 
importance  of  following  specifications  and 
documentation  standards  is  discussed  as  are  the 
difficulties  involved  in  time- estimating  and  progress 
control.  Several  significant  ideas  appear  including 
the  importance  of  desk-checking  (by  two  people) ,  of 
care  in  preparing  code  and  test  runs,  and  of  coDjplete 
and  accurate  records  of  all  development  decisions  and 
test  runs.  The  team  organization  for  supervision  of 
piogramming  is  used. 

Barnett70  2*9 

Barnett,  A.;  Training  Management  for  Effective  Data 
System  Development;  IFIP  World  Conference  on  Computer 
Education (1970) . 

T'his  paper  concentrates  on  the  activity  that  takes 
place  before  a  system  is  programmed.  The  premise  is 
that  management  must  be  trained  in  systems  development 
as  only  thus  can  data  systems  be  developed  to  perform 
the  required  functions  and  meet  realistic  and 
satisfactory  constraints. 


Aron70  3*7 

Aron,  J.D.;  Estimating  Resources  for  Large  Programming 
Systems;  in  Buxton,  J.N.,  and  Randell,  B,  (ed. ) ^ 
Software  Engineering  Techniques  (1970)  pp. 68-79. 
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Katzenelson? 1 


C822, 551 


1*6 


Katzenelson,  J.;  Documentation  and  the  Management  of  a 
Software  Project  -  A  Case  Study;  Software  -  Practice 
and  Experience;  vol.1,  no, 2  (April-June,  1971)  pp.147- 
157. 

This  article  "describes  and  summarizes  experience 
gained  by  a  university  software  project  ...  writing  a 
supervisor,  assembler,  and  debugging  aids  for  a  small 
4K  homemade  computer".  Although  useful  in  context,  (a 
university  software  project) ,  it  may  be  difficult  to 
adapt  these  ideas  to  a  large  application. 

Boehffl73 


Boehm,  B.w,;  Software  and  its  Impact:  A  Quantitative 
Assessment;  Datamation,  vol.  19,  no,  5  (May  1973) 
pp. 48-59, 

Gotterer69  C817,793 

Gotterer,  M.H.;  Management  of  Computer  Programmers; 
PLoceedings  of  the  SJCC,  vol.  34  (1969)  pp. 419-424. 

Liebowitz67  C812,170 

Liebowitz,  B.  H.  ;  The  Technical  Specification  -  Key  to 
Management  Control  of  Computer  Programming;  Procecjdings 
of  the  SJCC,  vol.  30  (1967)  pp. 51-59. 


TOPICS 

Other  management  papers: 

Corbato72,  Maynard72,  Mealy69,  Myers73,  Selig69, 
Steel65,  Tsichr itzis72 ; 

Cost  estimation: 

Aron70,  Bemer69,  Boehm73,  Evans70,  HalstGad73,  Haney72, 
Jackson70,  Masters68,  Maynard72,  KcMonig<:ili70 , 
Smith72b ; 

Project  scheduling: 

Bemer69,  Garwickbl,  Haney72,  McMonigall70,  Mealy69, 
Smith72b ; 
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Sim(Bons72  , 
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III.  .Design 

Myers73  1*20 


Hyers,  G. J, ;  Characteristics  of  Composite  Design; 
Datamation,  vol.19,  no.  9  (Sept.  1973)  pp.  100-102,. 

An  essentially  unsatisfying  discussion  of  design 
criteria  for  highly  modular  programs.  Suggests  that 
the  goal  is  a  program  composed  of  "strong”  (closely- 
coupled  internally)  modules,  each  with  a  well-defined 
function  and  predictable  results,  linked  by  as  few 
arguments  as  possible.  No  real  life  example  of  such 
design,  or  its  supposed  advantages  (guickly  written, 
easily  debugged,  easily  changed)  is  provided. 

Program  structure  follows  social  structure 
(‘furski70)  .  The  two  key  statements  in  the  paper  are: 
"Because  of  the  high  independence  within  the  program, 
interactions  and  dependencies  among  programmers  are 
reduced.”  ’’Programmer  assignments  can  be  easily 
shifted  to  smooth  out  the  peaks  and  valleys  on  resource 
requirements. " 

Ulrich70  10*16 


Ulrich, 
Operation 
(ed) ,  Sof 
153. 


W.;  Design  of  High  Keliability  Continuous 
Systems;  in  Buxton,  J.N.,  and  Randell,  B. 
tware  Engineering  Techniques  (1970)  pp.149- 


Parnas72e  CR25,351  4*16 

Parnas,  D.L.;  Information  Distribution  Aspects  of 
Design  Methodology;  Proceedings  of  IFIP  Congre.^is  71, 
vol.  1  (1972)  pp. 339-344. 

The  thesis  of  this  paper  is  that  a  designer  may 
retain  tighter  control  on  the  structure  of  his  system 
if  he  controls  the  distribution  of  information.  Parnas 
observes  that  "a  good  programmer  makes  use  of  the 
useable  information  given  him”.  The  consequence  is 
that  a  good  programmer,  given  all  the  information  about 
the  system  design  will  always  find  some  efficiencies  in 
"bit  twiddling".  The  unfortunate  side  effect  is  that 
modules  become  highly  interconnected,  making  for  nasty 
problems  later  in  the  design.  Restriction  of 
information  distribution  reduces  this  interdependency. 
Information  about  design  decisions  can  now  be  used,  by 
the  designer,  to  verify  that  the  code  produced  is 
consistent  with  design  objectives.  Several  good 
examples  are  given  which  support  the  theme  of  the 
paper. 
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Liskov72  Ck2':),795  ,1*16 

Liskov,  B.H.;  A  Desigti  Mothodology  for  Koliablo 
Software  Systems;  Proceedings  or  the  FJCC,  vol.41 
(1972)  pp. 191-199. 

This  paper  presents  a  methodology  tor  the 
development  of  reliable  software.  It  begins  by 
justifying  the  development  of  such  a  methodology  in 
light  of  the  failure  of  existing  methods  (involving 
exten;jive  debugging)  to  produce  reliable  software.  The 
authoL  then  describes  a  two-part  methodology  derived 
fiom  her  own  experience  with  a  largo  software  project. 

T’he  first  part  involves  the  definition  of  a  ’'good" 
system  modularization,  in  which  the  system  is  organized 
into  a  hierarchy  of  "partitions"  each  corresponding  to 
a  level  of  abstraction,  ana  having  minimal  connections 
with  one  another.  The  total  system  design  is  then 
expressed  as  a  structured  program,  rendering  the  design 
amenable  to  existing  proof  techniques. 

ihe  second  part  looks  at  the  question  of  how  to 
achieve  a  system  design  with  good  modularity.  The  key 
to  the  design  is  seen  by  the  author  as  the 
identification  of  "useful"  abstractions  which  help  the 
designer  to  think  about  the  system.  Some  techniques 
for  finding  such  abstractions  are  given.  A  definition 
Of  "end  of  design"  is  given,  involving  having  a  system 
design  with  the  desired  structure,  and  a  preliminary 
user's  guide. 

ihe  paper  ends  by  describing  experiments  in  the 
use  of  the  methodology  in  progress  at  the  time  of 
presentation. 

BaLton70  CR2  1,44  5  7*15 

Barton,  R.S.;  Ideas  tor  Computer  Bysteins  Organization: 
A  Personal  Survey;  in  Tou,  J.T, (ed) ,  Software 
Engineer ingj_  vol.1.  Academic  Press,  New  York  (1970) 
pp. 7- 16. 

Barton  presents  arguments  in  support  of  his 
preferences  for  a  large  variety  of  systems  features. 
In  the  paper  he  supports  varying- length  over  fixed- 
length  paging,  variable-length  slices  for  partitioning 
processor  time,  Polish  notation  for  expressing 
statements  and  procedures,  structured  programming 
Without  GOTO's,  the  elimination  of  directly  controlled 
indexing  (i.e.,  APL  type  operations  are  preferable), 
and  varying  length  (programmer-defined)  storage 
mappings. 
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Parnas71  5*15 

Parnas,  D.L,;  A  Paradigm  for  Software  Module 
Specification  with  Examples;  Car negie- Mellon 
University,  Department  of  Computer  Science  (March  1971) 
pp, 1- 19. 

Cox71  2*15 

Cox,  P.F,;  Machine  -  Independent  Operating  Systems:  A 
Functional  Approach  To  Design;  in  Hugo,  J.S.  (ed.).  The 
Fourth _ Generation^  Infotech,  Ltd,  (1971)  pp. 239-258. 

The  term  operating  system,  as  currently  used  in 
the  computer  industry,  is  virtually  undefinable.  There 
is  a  large  set  of  functions  that  nearly  all  operating 
systems  do  perform,  but  this  set  is  inclined  to  become 
a  little  fuzzy  around  the  edges. 

In  this  paper,  Cox  attempts  to  set  forth 
objectives  that  are  required  in  a  machine  -  independent 
operating  system  and  portable  software  at  the  higher 
level.  He  feels  that  more  thought  is  required  as  to 
the  function  of  operating  systems  and  the  philosophy 
behind  them,  rather  than  on  what  a  particular  machine 
or  a  particular  operating  system  does. 

Bushnell71  1*15 

Bushnell,  K.C,;  User  Modifiable  Software;  H^thematical 
Academic  Press,  New  York  (1971)  pp.  59-66. 

This  paper  presents  arguments  for  easy- to- modify 
software  in  a  short,  well-written  paper.  Although 
written  with  regard  to  mathematical  systems,  the 
suggestions  given  on  how  to  write  modifiable  software 
can  have  wider  applicability. 

0rga3s69  CRIB, 260  1*15 

Orgass,  R.J.,  and  Waite,  W.M,;  A  Base  for  a  Mobile 
Programming  System;  Communications  of  the  ACM,  vol.12, 
no. 9  (Sept.  1969)  pp. 507-510. 

This  paper  presents  an  algorithm  for  a  macro 
processor  which  has  been  used  as  the  base  of  an 
implementation,  by  bootstrapping,  of  processors  for 
programming  languages.  This  bootstrapping  procedure 
does  not  require  a  running  processor  on  the  old  machine 
for  its  implementation.  Using  this  algorithm, 
transferring  a  language  to  a  new  machine  has  been  done 
within  one  man-week. 
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DijkstL<i69  9*14 

Dijkstra,  E.W.;  Complexity  Controlled  by  Hierarchical 
Ordering  of  Function  and  Variability;  in  Naur,  P.,  and 
Randell,  B.  (ed.).  Software  Engineering  (1969)  pp.181- 
1  do. 


The  principle  of  operating  system  design  as  an 
ordered  sequence  of  machines,  each  succeeding  one  more 
attractive  (to  the  user)  is  presented.  Each  machine  is 
implemented  by  an  additional  layer  of  software  over  the 
basic  machine,  ft  description  and  justification  for  the 
particular  layers  used  in  the  T.H.E.  System  is  also 
given. 

PaLnas72b  CR23,949  7*14 

Parnas,  D.L,;  A  Technique  for  Software  Module 
Specifications  with  Examples;  Communications  of  the 
ACM,  vol.  15,  no.  5  (May  1972)  pp. 330-336. 

An  approach  to  writing  software  specifications  for 
parts  of  systems  is  presented.  This  is  an  example  of 
Dijkstra's  principle  of  non-interference.  The 
technique  attempts  to  provide  specifications  with 
sufficient  information  to  allow  interaction  of  the 
parts  only  as  a  whole.  Parnas  suggests  a  structure 
where  specifications  could  be  tested  for  completeness 
and  correctness  before  detailed  coding.  Although  the 
idea  is  at  a  young  stage  his  analysis  to  this  point  is 


useful 

and  worth  noting. 

Par  nas72c 

CR2b,  197 

6*  14 

Par  nas. 
Systems 
vol . 15, 

D.L.;  On  the  Criteria  Used  in 
into  Modules;  Communications  of 
no. 12  (Dec.  1972)  pp. 1 053- 1 058 . 

Decoffl  posing 
the  ACM, 

Modularization  involves  decomposition 

ot 

the 

problem  into  modules  corresponding  to  each  major  step 
in  the  processing.  Parnas  shows  by  example  that 
modifying  the  data  structure  specifications  (i.e., 
storage  media,  packing  of  information,  input  format) 
would  require  an  extensive  rewriting  of  most  modules. 
He  suggests  that  for  systems  greater  than  5,000-10,000 
instructions,  the  criterion  ot  'information  hiding'  be 
used  to  guide  decomposition.  Every  module  is 
characterized  by  a  design  decision  it  hides  from  all 
other  modules.  Although  efficient  implementation  may 
involve  a  reshuffling  of  the  module  code  to  produce  the 
final  system,  maintaining  both  levels  of  code  would 
combat  this  objection. 
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Mealy69  CH19,621  S'i'IU 

Mealy,  G.H.;  The  System  Design  Cycle;  Proceedings  ACM 
Second  Symposium  on  Operating  Systems  Principles  (Oct. 
1 969)  pp, 1-7. 

The  steps  in  a  design  of  a  project  are  discussed 
along  with  popular  design  pittfalls.  The  steps  are 
divided  as  follows: 

1.  Gross  design  (or  architecture) 

2.  Design  plan  for  next  stages  of  project 

3.  Detailed  design  of  project 

4.  Developcaent  plan  (implementation) 

Also  the  author  feels  that  programmers  underrate  the 
importance  of  market  considerations  in  system  design 
and  that  technical  competence  should  include  an 
appreciation  of  these  problems.  Among  the  problems 
discussed  are  headlong  rushes  to  implement  without  a 
complete  and  evaluable  design,  inadequate  market 
information,  and  ignorence  of  Conway’s  Law  which  states 
that  systems  resemble  the  organizations  which  produced 
them . 

Cohen72  2*14 

Cohen,  A.;  Modular  Programs:  Defining  the  Module; 
Datamation,  vol.18,  no,  1  (Jan.  1972)  pp.  34-37. 

Modular  programming  is  a  useful  tool  if  applied 
skillfully.  The  author  gives  a  feeling  tor  the  right 
decomposition  of  your  problem  into  modules  by 
considering  typical  file  processing  programs. 

Strachey71b  2*14 


Strachey,  C. ;  The  Interaction  of  Software  Engineering 

and  Machine  Structure;  in  Hugo,  J.S.,  The _ Fourth 

Generatiorij^  Infotech,  Ltd.,  Berkshire,  England  (1971) 
pp.  34  1-356 . 
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s  system  is  a  process  and  these  are 
n  hierarchical  levels  which  serve  to 
independent  abstractions .  Program 
and  verification  are  briefly  discussed  and 
dix  gives  some  explanation  of  semaphores 
Its  on  prevention  of  deadlock. 
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8an(3ellb9 


10«13 


Kandell,  B.T.;  Towards  a 
System  Design;  in  Naur, 
Software  Engineering  (1969) 


Methodology  of 
P. ,  and  Kandell, 
pp. 204-208. 


Computing 
B.  (ed. )  , 


Gunder  man?  3 


5+13 


Gundernian,  H.  E,  ;  A  Glimpse  into  Program  Maintenance; 
Datamation,  vol.19,  no. 6  (June  1973)  pp. 99-101. 


Program  maintenance  is  described  as  '*a  large  and 
continually  growing  area  of  activity  which  is  taking 
its  toll  in  time,  money,  manpower,  computer  use, 
profits,  etc.’*.  These  problems  are  attributed  to 
maintenance  having  been  largely  ignored,  or  viewed  as 
an  activity  for  second  class  programmers  who  are  not 
yet  capable  of  original  program  development.  The  lack 
of  published  literature  and  research  on  debugging:  is  a 
problem.  A  typical  system  problem  and  the  implications 
of  fixing  it  are  described  and  the  organization  of  an 
effective  "maintenance  facility"  is  discussed. 


Belady 7  I 


13 


Belady,  L.A.,  and  Lehman,  M.M,;  Programming  System 
Dynamics  or  the  Meta- Dy nara Lcs  of  Systems  in  Maintenance 
and  Growth;  IBM  Research  Center,  Yorktown  Heights, 
N.Y.,  no.  RC  3546  (September  1971). 

Parnas72d  CR2b,506  5*12 


Parnas,  D.L.;  Some  Conclusions  from  an  Experiment  in 
Software  Engineering  Techniques;  Proceedings  of  the 
FJCC,  vol.41  (1972)  pp. 325-329. 

Describes  a  student  group  project  to  test  the 
methodology  outlined  by  the  same  author  elsewhere. 
Once  the  problem  has  been  carefully  partitioned  into 
five  modules,  each  module  was  assigned  to  several 
different  students,  sometimes  with  different  internal 
specifications  for  each  student.  Care  is  taken  in  the 
decomposition  to  see  that  details  such  as  data 
structures  and  access  methods  are  "known"  to  as  few 
modules  as  possible,  usually  only  one.  The  result  of 
the  experiment,  192  working  combinations  out  of  a 
possible  1024,  is  regarded  as  a  success  considering: 
the  students  were  generally  poor  programmers,  some 
modules  were  not  finished,  the  language  used  was 
WATFIV,  etc.  The  final  integration  and  testing  of 
modules  was  done  by  someone  with  "absolute  no  knowledge 
of  the  structure  of  any  module". 
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Dennis65 


CR10,085 


3*  12 


Dennis,  J.B.;  Segmentation  and 
Wul tiprogrammed  Computer  Systems;  Jo 
vol.12,  no. 4  (October  1965)  pp. 589-602 
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Madnick,  S.E.,  and  Alsop,  J.W.;  A  Modular  Approach  to 
File  System  Design;  Proceedings  of  the  SJCC,  voi.34 
(1969)  pp.1-13. 
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CR22, 799 


3*12 


Balzer,  R.M.;  PORTS  -  A  Method  for  Dynamic  Interprogram 
Communication  and  Job  Control;  Proceedings  of  the  SJCC, 
vol.38  (1971)  pp, 485-489. 
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output  of  two  or  more  components  of  the  system,  Balzer 
explains  his  ideas  in  terms  of  his  Incremental  Systems 
Programming  Language  which  uses  an  extension  of 
Dijkstra’s  semaphores. 

Heissman71  2*12 


Weissraan^  L.;  Software  Interfaces  for  Computer  Systems; 
M.S.  Thesis,  University  of  Toronto,  Department  of 
Computer  Science  (1971)  pp,1-71. 


Communication  between  program  moaules  is  an  area 
of  increasing  importance  and  interest  in  the  design  and 
implementation  of  software  systems^  This  communication 
is  handled  by  interfaces,  which  can  be  dealt  with  using 
either  the  port  or  structure  approach.  In  comparing 
the  two  approaches  the  structure  approach  was  chosen  as 
the  more  satisfactory.  Problems  exist  with  the 
structure  approach  primarily  because  modules  are 
allowed  physical  access  to  interface  structures.  In  an 
attempt  to  solve  some  of  the  problems  inherent  in  the 
structure  approach,  an  interface  system  has  been  built 
for  handling  comiaunication  between  program  modules. 
The  interface  system  gives  the  modules  logical,  rather 
than  physical,  access  to  interface  structures  and 
regulates  the  type  of  access  a  module  may  have  to  a 
particular  structure^  The  interface  system  was  used  in 
the  design  and  implementation  of  an  information 
retrieval  system, 

Hopkins70  1*12 


Hopkins,  Computer  Aided 
Buxton,  J,N.,  and  Randell, 
Engineering  Techniques  (1970)  pp. 
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Steel67  CH13,919  3*11 

Steel,  T.B.j  Standards  for  Computers  and  Information 
Processing;  in  Alt,  and  Hubinoff,  M.  (ed,), 
Advances_in_Computers^  vol.  8  (1967)  pp,  103-152, 


With  such  diversity  in  the  field  of  computer 
science,  some  form  of  unification  most  be  taken. 
Standardization  of  the  terminology,  problem  definition, 
programming  languages,  communication  characteristics 
and  physical  (i^e.,  nonelectrical)  characteristics  of 
computers  and  information  processing  devices,  equipment 
and  systems  is  a  must. 


"The  present  chaos  in  programming  languages  is  so 
bad  thar  it  is  often  compared  to  the  Tower  of  Babel, 
and  any  help  is  worth  having”.  The  complexity  in 
attempting  to  standardize  programming  languages  -  an 
almost  imposible  task  -  is  recognized.  The 
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developments  and  accomplishments  in  the  universal 
standardization  of  the  languages,  Algol,  Fortran  and 
Cobol,  are  related. 
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2*  1 1 


Dakin,  H.J.,  and  Poole,  P.C.;  A 
The  Computer  Journal,  vol.16, 
pp. 219-222. 


Mixed  Mode  Approach; 
no. 3,  (August  1973) 


This  paper  uses  the  development  of  a  versi 
the  MITEM  text  editor  to  describe  the  notion  of 
coding.  This  consists  of  using  interpretive  and 
code  in  the  same  system.  Also  discussed  a 
adaptability  of  code  generation,  selective  optimi 
of  run  tiaie  and  program  space  in  code  generation. 

The  system  was  first  run  in terpreti vely 
monitored,  to  discover  that  ninty-seven  percent 
execution  time  was  spent  in  less  than  ten  per  ce 
the  source  code.  These  frequently  executed  po 
were  changed  to  direct  code,  and  the  rest  of  the 
was  left  interpretive.  This  mixture  combines  the 
of  direct  code  and  the  efficient  space  utilizati 
interpretive  code.  The  run-time  overhead  of  mixe 
was  found  to  be  very  slight  ana  it  ran  three  to 
times  faster  than  the  interpretive  code,  while 
only  10-20%  slower  than  the  direct. 

Another  benefit,  which  is  discussed,  is 
adaptability  of  the  software,  which  it  creates, 
having  some  interpretive  code,  gives  powerful  deb 
and  easy  monitoring  capabilities.  Finally  the 
gives  some  ideas  on  how  a  mixed  code  so 
development  system  might  operate. 
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Mosedale,  T.W.;  PEDANT:  A  Computerized  Support  to 
Program  Modularity  Under  Limited  Memory  Conditions; 
Software  -  Practice  and  Experience,  vol.3,  no.  2 
(April-June  1973)  pp. 121-143. 

The  author  notes  that  the  "building  block 
approach"  is  already  used  in  hardware,  and  suggests  its 
extension  to  software.  He  points  out  that  modularity 
does  not  always  eliminate  the  driver/buffer  program. 
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but  requires  a  skillfully  created  interface.  PEDi!  NT  is 
designed  to  work  with  large  modules,  to  simplify 
applications  where  memory  size  is  small.  Data  areas 
are  considered  to  be  undefined  until  referenced,  and 
thus  outside  the  module  blocks.  PEDANT,  acting  as  an 
interpreted,  handles  all  requests  for  data,  and  for 
communication  with  other  modules*,  PEDANT  is  basically 
a  link  and  load  software  system.  Modules  can  ignore 
the  source  of  data  (i.e.,  in-core,  disk,  tape)  and  can 
treat  data  as  a  resource. 

Weller73  1*11 

Weller,  M.F.;  Heport  of  Session  on  Transferability; 
SIGPLAN  Notices,  vol„8,  no. 9  (September  1973)  pp. 11-16. 

The  report  discusses  two  aspects  of  portability 
"Today's  Transferability  Problems"  and  "Future  Systems 
Design  for  Transferability".  Short  discussions  are 
given  on  the  following  aspects  of  portability: 
emulation,  standardization  and  consideration  of  an 
operating  systems  interface  as  an  abstract  machine. 
Similarly  various  opinions  are  given  for  the  future 
design  to  improve  portability  such  as  extensible 
languages,  stressing  flexibility  and  levels  of 
transferability. 

Tsichr itzis72  21*10 

Tsichritzis,  D. ;  Lecture  Notes  on  Operating  Systems; 
University  of  Toronto,  Department  of  Computer  Science, 
no.  44  (August  1972)  pp.  1-290. 

This  readable  set  of  notes  gives  a  great  deal  of 
background  and  information  to  toth  the  technical  and 
managerial  aspects  of  software  engineering.  It  also 
contains  an  annotated  bibliography. 

Brinch  Hansen70  Ci<19,620  3*  10 

Biinch  Hansen,  P. ;  The  Nucleus  of  a  Multiprogramming 
System;  Communications  of  the  ACM,  vol.13,  no. 4  |April 
1970)  pp. 238-241 ,2S0. 

Habermann73  3*10 

Haber manr- ,  A.N.*  Integrated  Design;  SIGPLAN  Notices, 
vol.8,  no. 9  (September  1973)  pp. 64-66. 

An  argument  is  given  for  the  integration  of  the 
design,  analysis,  and  implementation  efforts  of  a 
programming  system  into  one  production  effort  in  which 
documentation  is  a  primary  issue.  Also  it  is  argued 
that  the  design  concepts  should  not  be  presented  in  the 
language  chosen  for  implementation  as  it  may  dominate 
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the  project. 

Brown71  CR23,004  2*10 

Brown,  F.D,,  Calderbank,  V.J.,  and  Poole,  H.D.;  Some 
Comments  on  the  Portability  of  a  Larije  ALGOL  Proijram  - 
The  Implementation  of  SID  on  KDF9;  Software  -  Practice 
and  Experience,  vol.1,  no. 4  (Oct. -Dec.  1971)  pp.367- 
371 . 
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Bcl Ir oy ,  M . D, ; 
Naur ,  P. ,  and 
(1969)  pp. 138- 
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A lexander , 
University 


;  Notes  on  the  Synthesis_of_Forjng 
Press,  Cambridge  (1964). 


Harvard 


Denil7  3 


1*10 


Denil,  N.J.;  Software  Design  with  Invocation  Diag 
SIGPLAN  Notices,  vol.8,  no. 9  (September  1973)  pp- 5 

The  author  describes  a  medium  for  expre 
abstractions  of  programs  (especially  their  struct 
He  claims  programs  can  be  designed  top  down  with 
medium;  only  the  ’’logic  of  the  design"  is  crucial- 
medium  provides  for  diagrams  of  data  and  structur 
the  programs  as  observed  from  the  program  modules 
data  communicated  between  modules,  and  the  effects 
module  has  on  the  communicated  data. 
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1*10 


Taliaferro,  W.M.;  Modularity.  The  Key  to  System 
Potential;  Software  Practice  and  Experience, 
no. 3  (July-Sept.  1971)  pp. 245-257. 
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Waite67 


1*10 


Wdite,  W.M.  A  Langud'jG 
Communications  of  the 
pp. 433-440. 


Independent  Macro  Processor; 
ACM,  voI.IO,  no. 7  (July  1967) 


A  string-manipulating,  language- independent , 
almost-machine-independent  macro  processor  is  presented 
in  this  paper.  The  output  from  this  macro  processor  is 
to  presented  to  some  compiler  or  assembler,  thus 
opening  up  many  useful  applications,  such  as  modifying 
a  compiler  without  the  necessity  for  a  complete 
redefinition  of  that  compiler's  language.  This  paper 
can  be  classified  as  an  high  level  application  to  the 
usage  of  macro  instructions  (in  assembly  language}. 

Corbdto72  CR25,199  6*9 


Corbato,  Saltzer,  J.H.,  and  Clingen,  C.T.; 
MULTICS  -  The  First  Seven  Years;  Proceedings  of  the 
SJCC,  vol.  40  (1972)  pp. 571-583. 


Although  intended  as  a  review  and  current  status 
report,  this  paper  provides  an  interesting  description 
of  the  progress  of  the  design  and  implementation  of  a 
very  large,  very  complex,  research  project  with  real 
iif®  goals.  In  their  conclusions,  the  authors  make  the 
point  that  computer  utility  systems  must  evolve,  since 
the  costs  of  redesign  and  re-implementation  are  too 
high  to  allow  any  other  procedure.  This  is  almost 
certainly  true  of  any  very  large,  complex  system  which 
is  to  serve  a  community  of  users  who  (1)  will  not  wait 
tor  the  ultimate  to  arrive  at  the  expense  of  not  doing 
anything  until  it  does;  (2)  are  used  to  a  particular 
environment,  and  see  no  real  need  to  unlearn 
everything . 

Judd70  Ck19,435  5*9 

Judd,  R. ;  Practical  Modular  Programming;  Computer 
Bulletin,  vol. 14,  no.  1  (1970)  pp.4-7. 


The  obvious  merit  of  modular  programming  is  that 
it  enables  programming  to  be  divided  among  several 
programmers  working  concurrently,  and  allows  better 
testing  and  validation  by  groups  who  may  not  be  aware 
of  the  detailed  methods  used  in  a  particular  module. 

The  author  of  this  paper  is  particularly 
interested  in  large-system  implementation  and  his 
treatment  of  modular  programming  contains  valuable 
suggestions.  At  times  his  viewpoints  differ  from  the 
current  standards  and  he  touches  on  some  con trov€irsial 
issues  such  as:  are  supervisors  really  capable  of 
reading  the  code  ot  their  subordinates,  should  a 
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coapany  employ  junior  programraers  to 
should  the  master  plan  of  a  project  be  k 
the  team  leader  and  should  the  junior  sta 
in  the  creative  aspects  of  the  project. 

In  the  author’s  opinion  no  definitio 
meaningful  if  it  disregards  the  applicat 
which  it  forms  a  part.  Certain  problems 
modules  fairly  obviously;  in  the  case  of 
programs  there  may  be  a  module  for  each 
for  each  transaction  type,  for  error 
processing  etc.  The  modules  should 
manageable  size  for  maintenance  purpose 
important  criterion  is  their  naturaln 
££2blefflj;_  Any  rigidity  in  the  design  of 
be  at  the  interface  level  and  not  at 
functioning  level.  The  paper  suggests  th 
control  should  be  handled  by  one  module  a 
to-module  calls  are  required,  these  shou 
through  a  'dispatching  module'  which 
linking  mechanism. 


save  expenses, 
no  wn  o  Illy  by 
ff  be  involved 


n  of  module  is 
ion  program  of 
define  their 
file  handling 
record  type, 
reports,  for 
be  kept  to 
s  but  the  most 

ess _ to _ the 

modules  should 
the  internal 
at  the  overall 
nd  if  module- 
id  be  executed 
operates  the 


Steel 6  5 


CK8 ,551 


4*9 


Steel,  T.B.;  The  Development  of  Very  Large  Programs; 
Proceedings  of  IFIP  Congress  1965,  vol. 1  (1965)  pp.231- 
235. 
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Parnas,  D.L.;  On  the  Use  of  Tra 
Design  of  a  User  Interface  for 
System;  Proceedings  of  the  24th 
(1969)  pp. 379-395. 


nsition  Diagrams  in  the 
an  Interactive  Computer 
ACn  National  Conference 


Parnas  discusses  the  design  of  the  u 
for  a  large  general  purpose  interact! 
particular,  he  proposes  that  a  terminal 
the  system  should  be  considered  to 
finite  number  of  states  and  that  input 
cause  transitions  to  other  states.  For 
power  is  turned  on,  the  terminal  might  be 
state  where  only  a  correct  "logon”  will 
some  state  where  further  messages  may 
According  to  Parnas,  the  use  of  such  a 
transition  diagram  should  lead  to  a  sys 
better  structured,  easily  documented, 
contain  errors,  and  perhaps  more  easily 
pieces  for  development.  From  the  user's 
system  should  be  easier  to  use,  more  flex 
some  cases  more  amenable  to  his 
modification. 
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!iadnick70  1*B 

Mddnick,  S,fi. ;  Design  Strategies  for  File  Systems; 

Project  MAC,  no.TR-78  (October  1970)  pp. 1-106. 

This  report  exemplifies  the  idea  of  "top-down"  or 
"levels  of  abstraction"  analysis  as  applied  to  the 
design  of  file  systems.  The  two  basic  concepts  imposed 
on  the  analysis  are  that  files  should  (except  for  the 
top-most  user  oriented  level)  be  subject  to  a  uniform 
representation,  and  that  the  tasks  of  naming,  storing 
and  retrieving  information  should  be  analyzed  into  a 
hierarchy  of  activities  ranging  from  the  purely  logical 
to  the  purely  physical. 

A  file  is  viewed  as  a  named,  sequentially 
organized  (virtual)  memory.  That  is,  the  items  of 
information  in  the  file  are  considered  to  be  assigned 
to  sequential  "addresses".  The  fact  that  the  items  are 
(say)  related  by  a  tree  structure  is  of  no  interest 
except  in  the  top-most  user-oriented  level  of  the 
system. 
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Halstead,  Natural  Laws  Controlling  Algorithm 

Structure?;  SIGPLAN  Notices,  vol.7,  no. 2  (February 
1972)  pp. 22-30. 

The  author  proposes  that  algorithms  obey  natural 
laws,  which  are  based  on  two  independent  properties, 
the  number  of  distinct  operators  and  the  number  of 
distinct  operands.  A  certain  function  of  these 
properties,  called  the  Internal  Quality  of  an 
algorithm,  is  said  to  be  independent  of  the  language  in 
which  the  given  algorithm  is  expressed.  Though  the 
results  are  inconclusive,  the  potential  implications  in 
programming  design  should  warrant  further  research. 
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Cost  reductions,  particularly  in 
of  large  scale  FORTRAN  scientific 
are  desirable,  but  are  not  easy  to  re 
enduring  development  problems  asso 
programs.  This  paper  examines  the  mo 
these  problems  and  suggests  ways  t 
problems  addressed  here  were  identifi 
of  years  spent  developing  a  famil 
simulation  programs  at  Boeing, 
discussed  were  evolved  during  the  de 
programs  and  are  of  proven  effective 
emphasis  is  placed  on  the  use  of  high 
interprogram  communication  techniques 
coding  practices. 
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Dijkstra,  E.H.;  Notes  on  Structured  Programming;  in 
Dahl,  O.-J.,  Dijkstra,  E.W,,  and  Hoare,  C.A.R.  (ed.); 
Structured_Procjrammingi  Academic  Press,  N.Y.  (1972) 

pp.  1-82. 
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Dijkstra,  E.W.;  The  Humble  Programmer;  Communications 
of  the  ACM,  vol.  15,  no.  10  (October  1972)  pp.859- 
886 . 

The  author  reflects  on  the  historical  development 
of  programming.  Initial  hardware  constraints  and  the 
nature  of  the  slowly  developing  field  resulted  in 
puzzle-minded  programmers  that  optimized  the  computing 
process.  The  introduction  of  second  and  third 
generation  computers  only  heightened  the  problems. 

In  looking  to  the  future  he  foresees  that  projects 
that  are  of  limited  size  now  will  be  done  with  much 
less  effort  and  many  fewer  bugs.  This  will  be 
accomplished  by  limiting  ourselves  to  ” intellect ually 
manageable  programs".  A  number  of  reasons  for  this  are 
given,  as  well  as  some  impediments.  To  be  humble 
programmers,  it  is  necessary  to  realize  the  magnitude 
of  the  problems,  the  usefulness  of  the  tools,  and  the 
limitations  of  the  human  mind. 
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Programming;  Eindhoven  University, 
1971)  pp. 1-97. 
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A  Survey  of  Control  Structures 
Programming  Languages;  SIGPLAN  Notices,  vol.  7, 
11  (November  1972)  pp.1-14. 
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This  paper  examines  the  control  structures  of 
programming  languages  and  how  the  constructs  are 
developed.  Progress  has  been  made  by  specialization 
through  composition  of  a  few  very  general  primitive 
operations.  The  dominance  of  the  underlying  sequential 
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machine  is  apparent  throughout  this  process.  In  some 
areas  this  specialization  has  lead  to  clarity?  and 
efficiency,  while  in  others  the  accompanying  loss  of 
generality  has  had  the  opposite  effect. 

Dijlcstra70  18’<‘17 

Dijkstra,  E.W,;  Structured  Programming;  in  Buxton, 

and  Randell,  B.  (ed.).  Software  Engineering 
Techniques  (1970)  pp. 84-87. 

A  discussion  of  the  amount  of  reasoning  required 
to  understand  an  arbitrary  program  leads  to  the 
conclusion  that  the  production  of  a  correct  program  can 
be  accomplished  most  easily  by  successive  refinement  of 
an  abstract  program, 

Mill372  15’<‘17 

Wills,  H.;  Mathematical  Foundations  of  Structured 
Programming;  IBM  Federal  Systems  Division,  no.FSC72- 
6012  (February  1972)  pp,1-62. 

Dijkstra65a  CR9,006  13’<'17 

Dijkstra,  Programming  Considered  as  a  Human 

Activity;  Proceedings  of  IFIP  Congress  1965,  vol.l 
(1965)  pp. 213-217, 

i’he  main  thrust  of  this  paper  is  that  the 
programmer  and  his  mi'’:!  are  an  important  part  of  the 
computing  process.  The  use  of  these  parts  of  the 
process  is  not  necessarily  optimized  by  making  poorer 
use  of  the  machine.  Rather  there  can  be  a  gain  in 
efficiency  of  usage  of  the  machine  by  using  top-down, 
GOTO-less  program  structuring  which  is  more  easily 
created  and  understood  by  humans. 

The  paper  suggests  that  investigation  be  done  to 
see  to  what  degree  the  goals  of  humans  and  the 
characteristics  of  the  machine  are  parallel,  and  that 
we  do  not  flatly  assume  that  these  are  opposites. 

The  author  asserts  that  elegance  leads  to 

desirable  features  of  programming  languages.  As  the 
title  implies,  he  approaches  programming  through  the 
basic  pattern  of  human  understanding.  From  this 

attitude  he  criticizes  programming  to  date  and 

describes  more  natural  and  elegant  structures. 

Dijkstra  gives  a  clear  statement  of  successive 
refinement  of  a  problem,  emphasizing  (1)  division  into 
parts,  (2)  the  parts  together  form  the  whole,  and  (3) 
the  principle  of  non-interference.  Here  also  are  his 
classic  arguments  for  program  correctness  and  against 


the  ”GO-TO”.  He  proposes  tour  desirable  Ian 
features  and  concludes  that  an  area  for  work  is  th 
the  compromises  of  efficency  against  convenience. 

Di jkstra68a 

Dijkstra,  E.W.;  Go  To  Statement  Considered  Har 
Communications  of  the  ACM,  vol.11,  no. 3  (Mar, 
pp. 147-148. 

The  concept  of  independent  co-ordinates  with 
to  describe  the  progress  of  a  process  is  discu 
Such  co-ordinates  cannot  be  found  if  unstruc 
control  transfers  are  allowed  in  programming  langu 
Suggestions  are  made  for  alternative  constructions 
are  both  flexible  and  structured  so  that  an  indepe 
co-ordinate  system  can  be  maintained. 
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Wiith,  N.  ;  Program  Development  by  Stepwise  Refine 
Communications  of  the  ACM,  vol.14,  no. 4  (April 
pp. 221-227, 


Programming  is  usually  taught  by  exam 
Unfortunately  these  do  not  usually  demonstrate  w 
applicable  techniques,  rather  they  show  what  a  com 
can  do,  Wirth  proposes  a  better  method  of  teac 
that  of  stepwise  refinement. 


Stepwise  refinement  is  intended  to  demonstrat 
gradual  development  of  a  program.  As  an  example, 
takes  the  eight  queens  problem  and  applies  the  me 
First  the  problem  is  stated  in  very  general  t 
leaving  many  details  unspecified.  The  proble 
gradually  refined  by  filling  in  details  at 
succeeding  step.  At  each  step  a  choice  is  made  a 
the  best  design  and  solution  for  that  level, 
process  continues  until  the  solution  is  expressibl 
a  programming  language. 


Wirth  concludes  that  this  method  success: 
splits  the  problem  into  a  number  of  subtasks  at 
step.  The  degree  of  modularity  obtained  determine 
ease  or  difficulty  of  the  problem.  This  method  a 
one  to  express  the  problem  in  notation  that  is  na 
to  the  problem,  until  the  notation  of  the  pr. 
becomes  that  of  the  programming  language.  Each 
requires  concise  design  decisions  which  affec 
final  solution. 
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«ills71b  9*16 

Mills,  H. ;  Top  Down  Piogramming  in  Large  Systems;  in 
Rustin,  R.{ed.);  Debugging  Techniques  in  Larqg_SystemSj_ 
Prentice-Hall,  Inc.  (1971)  pp. 41-55. 

Top  down  programming  is  concerned  with  the 
’•expansion  or  funcrional  specifications  to  simpler  and 
simpler  functions,  until  statements  of  the  programming 
language  itself  are  reached”.  Two  principles  are 
involved  -  1)  verification  of  correctness  at  each  step 
and  2)  utilization  of  only  a  few  basic  control 
structures:  simple  sequencing,  IF  THEN  ELSE,  and  DO 
WHILE. 

The  ideas  presented  can  be  used  to  create  a 
structured  program  from  design  specifications,  or  given 
a  large  system,  reorganize  it  into  a  set  of  more 
readable  segments.  The  resultant  programs  can  be  read 
set^uen tially  in  small  segments,  each  segment  from  top 
to  bottom,  with  all  control  paths  visible,  because  of 
GO  TO  free  code  and  library  and  macro  facilities. 

Dijkstra62  CR6,649  6*16 

Dijkstra,  E.W.;  Some  Meditations  on  Advanced 
Programming;  Proceedings  of  IFIP  Congress  1962  (1962) 
pp..  535-538. 

In  this  paper  Dijkstra  reflects  on  several  topics. 
He  reviews  the  bad  architecture  of  past  machines  and  of 
the  then  largely  available  commercially- produced 
machines.  He  points  out  that  since  programming  is 
equivalent  to  machine  design,  programmers  should  accept 
the  responsibility  of  influencing  future  designs  by 
exploring  them  in  software.  ALGOL  60  is  mentioned  as 
an  entity  which  provoked  considerable  effort  in 
translator  writing  and  considerable  thought  about 
programming  languages.  Puzzle- minded  programming  is 
criticized  in  favor  of  a  systematic  approach. 
Correctness,  reliability  and  their  demonstration  are 
emphasized.  Dijkstra  concludes  with  a  desire  to  see  a 
symbiotic  craf tsman-and-his-tools  relationship  develop. 

Mills73b  3*16 

Mills,  H.D.;  On  the  Development  of  Large  Reliable 
Programs;  IEEE  Symposium  on  Computer  Software 
Reliability,  New  York  (April  1973)  pp. 156-159, 

In  this  paper  Mills  describes  operational 
procedures  intended  for  the  development  of  large 
reliable  programsc  These  procedures  are  based  on  top 
down  structured  programming  to  proviae  small  structured 
program  segments  which  facilitate  reading  of  program 


text  and  testing.  With  respect  to  overall  program 
correctness,  the  approach  taken  is  that  rather  than 
have  to  claim  that  the  last  error  has  been  found  (if 
that  is  possible)  one  should  strive  to  never  find  the 
first  error.  Mills  feels  this  can  be  accomplished  by 
restructuring  programming  from  a  private  art  into  a 
public  practice  by  having  programs  read  by  others. 
Finally,  the  paper  introduces  the  concept  of  program 
development  accounting  as  a  means  to  record  the  process 
of  program  development  and  insp^ection,  and  to  provide 
proof  of  the  successfulness  of  the  concept  of  never 
finding  a  first  error  in  the  program. 

Wulf72c  CR24,717  3*16 

Wulf,  W.A.;  Programming  Without  the  Goto;  Proceedings 
of  TFIP  Congress  71,  vol.  1  (1972)  pp, 408-412. 

Hulf73  12*15 


Wulf,  W. ,  and  Shaw,  M, ;  Global  V 
Harmful;  SIGPLAN  Notices,  vol, 8, 
pp, 28-34. 

An  extension  of  Dijkstra's 
GOTO's  to  global  variables  -  v 
modified  over  large  portions  of 
richer  methods  of  defining  vari 
Algol  block-structured  approach.  E 
able  to  limit  access  to  stacks  and 
routines  only^ 
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Hoare,  C.A.H.;  Notes  on  Data  Structuring;  in  Dahl,  0.- 
J.,  Dijkstra,  E.W.,  and  Hoare,  C,A,R.;  Structured 
££23£3m|ni  ngj_  Academic  Press,  New  York  (June  1972) 
pp.  83-  174 . 


The  author 
the  motion  of 
and  programming 
the  notion  of 


motivates  the  monograph  by  presenting 
abstraction,  illustrated  by  real-world 
language  examples.  Within  this  setting 
a  type  is  given,  with  special  attention 
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devoted  to  the  operations  defined  for  values  of  a  type. 
A  detailed  description  of  structuring  operations  on 
types  is  given,  emphasizing  the  meaning  of  the 
structures,  and  manipulations  and  representations  of 
values  of  the  structures.  An  example  illustrates  the 
use  of  the  structuring  operations  to  refine  abstract 
types.  Finally,  an  axioroatizaticn  of  the  types  is 
presented . 

Leaven  wort  h72  CH24,  148  2*M> 

Leavenworth,  Programming  With{out)  the  GOTO; 

Proceedings  of  the  ACM  1972  Annual  Conference  (1972) 
pp. 782-786. 

The  author  presents  a  brief  history  of  the  GOTO 
controversy.  The  GOTO  does  not  appear  in  formal 
systems  such  as  rhe  Post  system  or  Kleene  general 
recursive  functions,  but  has  been  added  to  programming 
languages.  The  existence  of  the  GOTO  as  a  primitive 
operation  on  machines  has  influenced  the  design  of  high 
level  languages.  The  author  summar izes  both  sides  of 
the  argument.  In  its  favor,  the  GOTO  is  needed  for 
abnormal  exits  from  blocks  or  procedures,  efficient, 
useful  for  synthesis  purposes.  However,  programs 
without  GOTOs  are  ©ore  easily  understood,  debugged,  and 
modified.  It  is  easier  to  prove  assertions  about 
programs  which  contain  no  GOTOs.  Finally,  the  GOTO  is 
freguently  misused  to  synthesize  more  sophisticated 
control  structures. 

McKeeman72  2*15 

McKeeman,  W.f!.;  Compiler  Structurej  First  USA-Japan 
Computer  Conference  (1972)  pp. 448-455. 

Brinch  Hansea73b  CR2b,104  1*15 

Brinch  Hansen,  P.  i  Operating__ Systems _ Elinciplesi 

Prentice- Hall ,  Inc.,  Englewood  Cliffs,  N.J,  (1973) 
pp. 1- 366. 

This  book  is  an  excellent  overview  of  the  problems 
and  trade-offs  inherent  in  operating  system  design;  it 


also  details 

the  current 

state 

of  their  solu 

tion. 

Chapters  two 

and  three 

present 

an  abstract 

vi 

ew  of 

computation 

processes. 

both 

sequential 

a  nd 

dsy  nchronous. 

Chapters 

four 

through  six 

di 

scuss 

techniques  of  implementing  processes  on  present-day 
computers.  Chapter  seven  outlines  the  emerging  field 
of  protection,  and  chapter  eight  describes  and  gives  a 
critical  analysis  of  the  operating  system  for  the 
RC4000.  This  book  is  required  reading  for  anyone  who 
would  design  a  large  system,  or  would  like  to  know  how 
such  a  system  should  be  put  together. 


37 


Hoare? la 


Approach ; 


CR23, 647 

t.  ;  Procedures  ani 
Symposium 


on 


1 

*  15 

am 

et 

ers: 

An 

A 

xio 

ma 

t  ic 

nt 

ics  o 

f 

Alg 

or  i 

th 

fflic 

li 

n 

(197 

1) 

pp. 

102 

-1 

16. 

is 

m 

whic 

h 

f  ac 

ili 

tates 

He 

nee 

ds 

to 

imp 

os 

e  a 

hich 

is 

t 

howeve 

r. 

a 

desirable  programming  feature. 

Wegbreit71  CH23,516 

Wegbreit,  B.;  The  ECL  Programming  System; 
of  the  FJCC,  vol,  39  (1971)  pp. 253-262. 


1*15 

Proceedings 


Henderson72 


9*  14 


Henderson,  P.,  and  Snowdon,  B.;  An  Experiment  in 
Structured  Programming;  BIT,  vol,  12  (1972)  pp. 38-53. 

An  example  of  top-down  development  of  a  program  is 
given  (the  example  is  a  program  to  process  telegrams) . 
Although  carefully  constructed  and  correct  in 
appearance,  the  program  contains  an  error.  The  process 
of  using  the  structure  to  locate  and  correct  the  error 
(as  opposed  to  patching  the  final  program)  is  examined 
to  see  if  error  location  is  improved  by  the 
structuring.  In  addition,  some  pitfalls  of  structured 
programming  are  described.  This  paper  is  a  good 
antidote  to  unalloyed  euphoria  about  structured 
programming . 

Knuth71a  9*14 


Knuth,  D.E.,  and  Floyd,  K.E.;  Notes  on  Avoiding  ”go  to” 
Statements;  Information  Processing  Letters,  vol. 1 ,  no.l 
(Feb.  1971)  pp. 23-31. 

This  paper  discusses  the  use  of  the  ’"goto” 
statement  and  methods  of  avoiding  them.  The  ’'goto” 
statement  can  be  replaced  by  a  procedure  call,  or  a 
program  segment  containing  a  "goto”  can  be  imitated  by 
using  an  iterative  loop.  The  methods  are  applied  to 
two  typical  programming  examples:  symbol  table 
searching  and  backtracking.  The  article  discusses  when 
certain  methods  are  desirable  and  when  they  would  only 
add  ambiguity  to  the  program. 

riills69  5*14 


Hills,  H. ;  The  Case  Against  GOTO  Statements  in  PL/I; 
IBH  Report,  no,C224H2  (April  1969). 


hrshov  72 


Cb!2  4 , 022 


14 


Ki.-ihov,  A.P.;  Aesthotics  nd  the  Human  Factor  in 
ProjL'aiiniii  nij  ;  Com  mu  nica  t  i  ons  of  the  ACM,  vol,  15,  no. 
7  (July  1972)  (p. 501-505, 

Knuth7J  2’!-' 14 

iSnuth,  D.t.;  A  Review  of  htructuied _ ht  o^  r  a  m 

Stanford  University,  Department  of  Computer  Science, 
I'echnical  Report  Si  A  M-C  S- 73- 3  7  1  (June  1  97  3), 

i-his  report  contains  a  detailed  reviev;  of  the  hook 

Structured _ P i o^ram mi nj  in  the  form  of  letters  to  each 

of  the  three  authors  (Dahl,  Dijkstra,  and  Hoare) .  Fach 
letter  is  opened  wita  very  flattering  compliments  to 
tl*e  author,  ana  then  discasses,  in  a  point  by  point 
fashion,  many  (som(,'t  iin  es  minute)  details  of  that 
author's  chapter  in  the  book. 

Knuth's  points  are  too  numerous  to  list.  They  are 
often  controversial,  inspiring  one  to  reread  portions 
of  the  hook  to  refresh  his  memory  and  "take  sides". 
Especially  interesting  is  Knuth's  application  of  Simula 
classes  (from  Dahl's  chapter)  to  a  problem  which 
Dijkstra  solves  in  his  chapter. 

lievergel t 70  0320,659  2-14 

ievergelt ,  J.,  and  Irland,  M.I.;  Bou  nee- an  d-S  k  i  p :  a 
Technigue  for  Directing  the  Flow  of  Control  in 
Pro-jrams;  The  Computei  Journal,  vol.  13,  no.  3  (August 
I'.r/O)  pp.  2  6  1-  252. 


ihe  bounce-and-sKi p  technigue  tor  directing  the 
flow  of  control  in  block  structured  programs  was 
developed  as  a  result  of  the  search  for  alternatives  to 
tlie  'go  to'  statement  which  was  guestioned  by  Dijkstra 
in  196B  as  a  desirable  feature  of  high-level 
programming  languages.  This  method  is  regarded  oy  the 
authors  as  an  efficient  way  to  implement  all  of  the 
coiiKison  control  statements  of  high-level  languajes  as 
well  as  a  tool  for  program  debugging. 

lou nee- a nd- ski p  provides  the  user  with  two 
options: 

1.  To  delay  tiie  use  of  the  result  of  a  test 

indefinitely 

2.  To  make  the  entry  and  exit  of  BEGLN-END  blocks 
conditional  upon  the  last  test  performed. 

Each  test  pertormed  is  coded  as  eitiier  neutral 
(its  result  lias  already  been  used)  ,  successful  or 
unsuccessful.  This  indicator  is  matched  to  a  list  of 
permissible  settings  of  the  indicator  associated  with 
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each  BEGIN  and  END.  Under  a  mismatch  condition  control 
is  prohibited  from  entering  through  a  given  BEGIN  and 
thus  it  skips  the  block,  or  control  is  not  allowed  to 
exit  through  a  given  END  and  hence  it  bounces  and 
positions  itself  just  after  the  corresponding  BEGIN. 

Benson73  1*14 

Benson,  J.P.;  Structured  Programming  Techniques;  IEEE 
Symposium  on  Computer  Software  Reliability,  New  York 
(April  1973)  pp. 143-147. 

The  paper  attempts  to  answer  the  question  ”What  is 
structured  programming?”  by  examining  the  different 
meanings  which  have  been  associated  with  the  term. 
Structured  programming  is  viewed  as  a  design 
methodology  by  examining  the  work  of  E.W.  Dijkstra  and 
H.D.  Mills.  It  is  viewed  as  a  coding  technique  (goto- 
less  programming)  in  the  light  of  the  work  by  Bohm  and 
Jacopini,  The  paper  serves  as  a  good  (and  brief) 
introduction  to  the  major  ideas  of  structured 
programming. 

Clark71  19^13 


Clark,  B.L,,  and  Horning,  J.J.;  The  System  La 
Project  SUE;  SIGPLAN  Notices,  vol.b,  no, 
1971)  pp, 79-88. 

The  authors  motivate  the  discussion  of  t 
Language  by  describing  the  Project  SUE  con 
produced  it.  They  then  list  the  langua 
criteria,  emphasizing  structure  (of  program, 
paragraphing) ,  efficiency  (of  compilation, 
and  implementation) ,  and  modifiability. 
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694  6*13 

Tool  for  System  Programming; 
(May  1969)  pp. 68-76, 
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One  of  the  more  important  aspects  of  the  MULTICS 
t  was  the  decision  to  use  PL/I  as  the  systems 
mentation  language.  This  paper  discusses  the 
ns  for  choosing  a  high  level  language  for  systems 
amming  and  the  reasons  why  PL/I  in  particular  was 
n  for  MULTICS.  The  difficulties  in  implementing 
anguage  and  some  of  the  evils  of  PL/I  in  such  an 
onment  are  discussed.  That  Honeywell  intends  to 
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make  the  system  coramercially  available  attests  to 
either  the  correctness  of  their  assumptions  or  extreme 
perseverence  in  the  face  of  adversity. 

Peterson73  CH26,  120 


Peterson,  W.W.,  Kasami,  T. ,  Tokura, 
Capabilities  of  While,  Repeat,  and  Ex 
Communications  of  the  ACM,  vol.l6,  no. 8 
pp . 50  3-51 2. 

Usinij  a  flowchart  formalism 
[Ashcroft  71],  this  paper  also  desc 
removiny  transformation  for  programs  us 
GOTOs.  This  transformation  results  i 
program  which,  in  general,  is  longer  than 
but  which  has  the  same  execution  time  as 
(Both  length  and  execution  time  are  incr 
transformation  of  Ashcroft  and  Ma 
transformed  programs,  however,  make  use  o 
and  multi-level  exit  primitives  (in  a 
then-else) «  The  absence  of  this  multi- le 
most  current  programming  languages,  ( 
languages  with  this  primitive  are  not  me 
its  positive  or  negative  contribu 
understandability  of  programs,  are  not  di 

Hopkins72 

Hopkins,  H.Eo;  The  GOTO  Controversy:  A 
GOTO;  SIGPLAN  Notices,  vol.  7,  no.,  11  ( 

pp,  59-62.. 
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3^  13 


Liskov,  B. ;  Report 
Programming;  SIGPLAN 
197  3)  pp.5-10. 


of  Session 
Notices,  vol . 8, 


on  Structured 
no. 9  (SeptemboL 


An  overview  of 
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abstract  data,  etc.  Th 
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be  provided  by  a  struct 


the  definition  of  structured 
including  levels  of  abstraction, 
e  discussion  includes  sections 
on,  construction  of  structured 
guistic  features  which  ought  to 
ured  programming  language. 


W  oodge  r7  2 


CR24, 757 


3*13 


Woodger,  M. ;  On  Semantic  Levels  in  Programming; 
Proceedings  of  IFIP  Congress  71,  vol.  1  (1972)  pp.402- 
407. 

This  paper  discusses  the  recognition  of  levels  of 
meaning  in  relation  to  the  programming  of  a  solution  to 
a  given  problem.  An  analogy  with  the  '’operating 
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manual”  of  a  machine  is  made  in  an  attempt  to  expose 
inadequacies  in  present  programming  practice.  The 
author  maintains  that  at  each  level  an  abstraction  of  a 
process  (whose  meaning  is  clear  without  reference  to 
the  other  levels)  must  be  made.  Finally,  he  argues 
that  conventional  programming  practices  tend  to  confuse 
these  levels,  and  that  subroutines  do  not  solve  the 
problem, 

Morris73a  1^13 

Horris,  J.H,;  Types  are  not  Sets;  ACM  Symposium  on  the 
Principles  of  Programming  Languages  (Oct.  1973) 
pp,  120-124, 

The  author  argues  that  objects  ot  a  type  should  be 
should  be  managed  (i.e,,  created  and  operated  on)  by 
the  owner  of  that  object.  He  proposes  a  module  block, 
which  can  selectively  provide  local  symbols  to  its 
users,  including  the  names  of  types,  A  module  has  sole 
write  access  to  values  of  its  local  types,  but  may  give 
out  read  access  to  such  values  if  it  chooses.  Proof 
rules  are  discussed  for  verifying  correct  use  of 
modules.  Finally,  the  author  relates  Simula  classes 
and  polymorphic  functions  to  his  modules. 

Holt73a  14*12 


Holt,  R.C.;  Teaching  the  Fatal  Disease 
Introductory  Computer  Programming  Using  PL/I;  SI 
Notices,  vol.8,  no. 5  (May  1973)  pp.8-23. 
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McCracken,  D.B.,  and  Weinberg,  G.M.;  How 
Readable  FORTRAN  Program;  Datamation, 
(October  1972)  pp. 73-77. 


to  Wr  i 
vol. 18 , 


For  ease  of  documentation  and  for  readabi 
programmers  should  observe  the  described 
concerning  comments,  ”goto”s,  do-loops,  compli 
expressions,  statement  numbers  and  variable  names. 
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Knu th7  1b 


C£<22, 300 


9*12 


Knuth,  D,E.;  An  Empirical  Study  of  FORTRAN 
Software  -  Practice  and  Experience,  vol. 
(April/June  1971)  pp. 105-1336 
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conclusion  which  may  be  drawn  is  the  importance  of  a 
frequency  counts  which  record  how  often  each 
•S  performed  in  a  typical  run.  With  the 
frequency  counts,  a  programmer  or  an 
compiler  may  optimixe  a  program  by  merely 
those  portions  of  his  program  which  are 
»st  f requently <7  and  thus  reduce  the  amount  of 
in  producing  efficient  programs. 
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5=!^  12 


Waite,  W.fl,;  Building  a  Mobile  Programming  System;  The 
Computer  viournal,  ^ol«13p  no.  1  ^February  1970)  pp.28- 
31. 


In  this  paper  the  author  discusses  a  technique 
which  he  believes  to  be  fundamental  to  the  improvement 
of  mobility  of  programming  systeroso  It  is  recognized 
that  the  mobility  of  a  programming  system  and  the 
associated  application  programs  is  an  extremely 
important  aspect  whenever  a  user  upgrades  or  changes 
his  equipment.  The  mobility  of  systems  software  is  a 
function  of  the  number  of  installations  which  are 
involved  and  in  general,  the  mobility  of  a  program  is 
completely  dependerst  on  the  mobility  of  the  progrcioiming 
system  it  utilizes. 

The  technique  to  provide  mobility  is  based  on  the 

concept  of  an  abstract _ Machine  -  a  hypothetical 

computer  ideal  for  a  particular  task.  The  program  for 
this  task  is  written  for  the  abstract  machine  and  to 
run  such  a  program  on  a  real  machine,  the  ab£:tract 
machine  must  first  be  realized  in  some  way. 

The  author  concludes  the  article  by  discussing 
both  the  advantages  and  disadvantages  of  the  technique 
of  abstract  machine  modelling  and  points  out  that  the 
system  has  proved  extremely  mobile  in  practice,  having 
been  implemented  in  less  than  one  man-week  on  nine 
different  occasions. 
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Wulf72ci 


5*12 


Hulf,  W.A.;  The  GOTO  Controversy:  A  Case  Against  the 
GOTO;  SIGPLAN  Notices,  vol.  7,  no.  11  (Noveaiber  1972) 
pp. 63-69. 


Wulf7 1b 


4*12 


iulf,  W..,  Geschke,  C,  ,  Wile,  D.  ,  and  Apperson,  J.; 
Reflections  on  a  Systems  Programming  Language;  SIGPLAN 
Notices,  vol. 6,  no. 9  (October  1971)  pp. 42-49. 

Naur69a  CR19,420  3^12 

Naur,  P. ;  Programming  by  Action  Clusters;  BIT,  vol.  9, 
no.  3  (1969)  pp. 250-258. 

Lang69  CH18,265  2^12 

Lang,  C.A.;  SAL  -  Systems  Assembly  Language; 
Proceedings  of  the  SJCC,  vol,  34  (1969)  pp, 543-555. 

Alexander71  2*12 

Alexander,  W.G.;  How  a  Programming  Language  is  Used; 
University  of  Toronto,  Computer  Systems  Research  Group, 
no,  10  (February  1972)  pp. 1-119, 

An  analysis  tool  is  discussed  and  developed  with 
which  an  XPL  programmer  may  determine  the  status  and 
dynamic  usage  of  time  and  the  distibution  of  machine 
instruction  usage  for  his  XPL  program.  Although 
limited  in  its  scope  to  one  language  it  is  a  good 
example  of  the  type  of  low  level  analysis  technique 
that  could  profitably  be  applied  to  any  large 
programming  project  to  pinpoint  unsuspected 
inefficiencies.  The  particular  implementation  used  is 
slow  because  it  relies  upon  operating  system  interrupts 
and  recoveries  but  does  produce  comprehensive  (although 
not  selectively  controlled)  data  analysis, 

Schneiderraan73  2*12 


Schneiderman,  B. ,  and  Scheuerroan,  P« ;  Structured  Data 
Structures;  State  University  of  New  York  at  Stony 
Brook,  Department  of  Computer  Science,  Technical  Report 
no.  16  (June  1973)  pp.1-34. 
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the  correctness  of  the  program.  This  is 
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structure  (e.g.,  list,  tree,  ring,  queue, 
ue) ,  restrict  the  permissible  operations 
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on  the  structure,  and  specify  execution  time  checks  to 
ensure  the  torni  of  the  structure  is  not  altered  (e.g., 
by  the  insertion  of  some  pointer).  The  authors  claim 
that  they  wish  to  eliminate  unrestricted  branches  or 
edges  (i.e.,  pointers)  from  data  structures  just  as  the 
goto  has  been  eliminated  to  avoid  poorly  structured 
programs.  They  also  claim  that  using  their  systeai  top- 
down  programming  can  be  achievea  in  terms  of  data 
structures  by  having  the  nodes  of  a  given  level 
structure  serve  as  headers  for  the  structures  at  the 
next  level. 

Wirth73  2*12 

wirth,  N. ;  Systematic _ Programming^ _ an _ Introduction; 

Prentice- Hall ,  Inc.,  Englewood  Cliffs,  N.J.  (1973) 
pp .  1-169. 

This  book  introduces  programming  as  the  ait  or 
technique  of  of  constructing  algorithms  in  a  systematic 
manner,  as  a  discipline  in  its  own  right.  No  specific 
area  of  application  is  emphasized.  This  book  is 
tailored  to  the  rseeds  of  people  who  view  a  course  on 
systematic  programming  as  a  (possibly  neglected)  part 
of  basic  mathematical  training.  Few  people  tieside 
Dijkstra  will  fail  to  profit  from  reading  it. 

Ioungs70  2*12 

Youngs,  Error-Pr oneness  In  Programming;  Ph.D. 
Thesis,  University  of  North  Carolina  at  Chapel  Hill, 
Department  of  Psychology  (1970)  pp.  1-147. 

This  thesis  basically  describes  a  progra  mining 
experiment  to  study  human  programming  errors  with  an 
eye  towards  suggesting  improveiinen  ts  in  progranaming 
languages  and  processors.  Although  no  startling  facts 
were  made  nor  strong  conclusions  reached,  this  thesis 
begins  to  develop  techniques  and  concepts  for 
quantifying  program  development.  The  thesis  is  rather 
easy  to  read,  and  it  is  interesting  to  see  how  he  codes 
and  evaluates  data  on  programming  errors. 

Cole73  1*12 

Cole,  N.M.,  and  Seikei,  M.J.;  Solving  a  Software  Design 
Problem  Using  Plain  English;  Datamation,  vol,19,  no.  10 
(October  1973)  pp. 101-106. 

This  article  describes  a  method  of  top-down 
program  design.  Plain  English  is  not  really  used,  but 
rather  a  high-level  macro  language.  The  macros  are 
written  by  top-level  programmers  familiar  with  the 
system,  and  the  information  content  of  the  macros  is 
such  that  low-level  programmers,  who  lack  the  detailed 
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knowledge  of  the  system,  can  flowchart  and  code  the 
ptograiB  without  too  much  difficulty.  The  authors  claim 
savings  in  time,  increased  efficiency,  and  more 
effective  use  of  prograratBer  resources. 
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Holt,  R.C.  and  Wortman,  D.B,;  Structured  Subsets  of  the 
PL/I  Language;  University  of  Toronto,  Computer  Systems 
Research  Group,  no.  27  (October  1973)  pp.1-27. 


This  paper  presents  a  sequence  of  subsets  of  the 
PL/I  language  developed  by  the  author  for  the  purpose 
of  teaching  introductory  programming.  The  subsets  are 
based  on  the  thoughts  given  in  ’’Teaching  the  Fatal 
Disease"  on  taming  PL/I  for  teaching  structured 
programming.  A  description  of  the  University  of 
Toronto's  SP/k  compiler  which  enforces  use  of  the 
subsets  is  given. 

Gries71  9*11 

Gries,  D.  ;  Coffl£iler_Const ruction_f or_Diqi tal_Coffipu ter s_p 
Wiley,  N.Y.  (1971)  pp.  1-493. 

Ashcroft72  Ch24,932  «*11 


Ashcroft,  E.,  and  Manna,  Z. ;  The  Translation  of  "go  to" 
Programs  to  "while"  Programs;  Proceedings  of  IFIP 
Congress  71,  vol.  1  (1972)  pp. 250-255. 

This  paper  demonstrates  that  every  flofcichart 
program  can  be  translated  into  an  equivalent  "while" 
program  without  "go  to"3  and  proves  that,  in  general. 
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new  variables  must  be  introduced  to  preserve  certain 
values  or  information  which  reflects  the  course  of 
computation. 

Brown70  8*11 

brown,  H.S.;  Software  Portability;  in  Buxton,  J.N.,  and 
Randell,  B.  (ed.).  Software  Engineering  Techniques 
(1970)  pp. 80-84. 

There  can  be  no  dispute  that  software  portability 
is  one  of  the  central  problems  in  software  engineering. 
Brown's  solution  to  the  problem  is  to  write  all  his 
sottware  (ALTBAN  F)  in  FORTHAN  with  a  macro  processor 
(H6)  which  accomodates  various  dialects  of  FORTRAN 
(e.g.  INTEGER  *  2  in  360  FORTRAN) .  This  is  perhaps 

sufficient  comment  on  the  state  of  the  art  of  software 
portability. 

McKeeman67  CR14,136  8*11 

McKeeraan,  W.M.;  Language  Directed  Computer  D^jsign; 
Proceedings  of  the  FJCC,  vol.  31  (  1967)  pp. 413-417. 

An  entertaining  article  which  begins  by  imagining 
what  would  happen  if  we  had  to  coaipile  on  a  computer 
modelled  after  a  Turing  machine  rather  than  on  one 
modelled  after  a  desk,  calculator.  The  author  comilains 
that  compilers  and  operating  systems  are  getting  less 
reliable  and  more  expensive  to  produce.  Among  the 
remedies  suggested  are; 

1.  Making  hardware  designers  write  a  compiler 

2 .  Not  designing  machines  with  multiple  arithmetic 
formats  and  the  attendent  conversion  problems 

3.  Replacing  the  ability  to  address  any  word  in  the 
machine  with  lexic-level  addressing 

4.  Building  common  needs  (e.g.,  a  scanner)  into  the 
hardware. 

"The  obvious  attack  for  programmers  and  hardware 
people  together  is  to  devise  a  language  which  reflects 
what  we  want  to  do  and  how  to  do  it  (for  instance,  in 
parallel)  and  machine  structures  effective  in  handling 
that  language." 

Feldman68  CR14,729  7*11 

Feldman,  J.,  and  Cries,  D. ;  Translator  Writing  Systems; 
Communications  of  the  ACM,  vol.11,  no. 2  (Feb.  1968) 
pp. 77-113. 

A  survey  of  the  state-of-the-art  in  translator 
writing  systems  up  to  1968.  It  is  a  useful  discussion 
on  the  automation  of  writing  translators  for 
programming  languages  and  includes  a  formal  study  of 
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syntax. 


Hoare69  Cai8,328  5*11 

Hoare,  C.A.R.;  An  Axiomatic  Basis  for  Computer 
Programming;  Communications  of  the  ACB,  vol.12,  no.  10 
(Oct,  1969)  pp. 576-580. 

Hirth71c  Ca23,196  4*11 

Wirth,  N,;  The  Design  of  a  PASCAL  Compiler;  Software 
Practice  and  Experience,  vol.  1,  no.  4 

(October/December  1971)  pp. 309-333. 

Wortman72  C£i25,416  4*11 


Wortman,  D.B.;  A  Study  of  Language-Directed  Computer 
Design;  University  of  Toronto,  Computer  Systems 
Research  Group,  no. 20  (December  1972)  pp.  1-207. 

Starting  with  a  ’’clean”  subset  of  PL/I,  the  author 
designs  a  computer  to  implement  its  semantics  directly. 
He  then  analyzes/predicts  its  pertormance,  and  in  the 
process  develops  tools  which  ’’could  also  be  used  by  the 
programmer  to  evaluate  the  performance  of  computers.” 
This  turns  out  to  be  the  major  useful  part  of  the  work, 
because,  as  he  points  out,  ’’for  languages  with  a  less 
elegant  structure  the  design  problem  is  much  more 
difficult , " 


Bergeron72 


3*11 


Bergeron,  B.D.,  Gannon, 
F.K.,  and  van  Dam,  A. 
in  Rubinoff,  H,  (ed.), 
12,  Academic  Press,  New 


J.D.,  Shecter,  D.P,,  Tompa, 
Systems  Programming  Languages; 

Advances _ ,in _ Computers^^  vol. 

York  (1972)  pp. 175-284. 


McKeeman66 


CR1 3, 436 


3*11 


McKeeman, 

Stanford 

Technical 


H.M;  An  Approach  to  Computer  Language  Design; 
University,  Department  of  Computer  Science, 
Report  CS4B  (August  1966)  pp. 1-124. 
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2*11 


Morris,  J.H.;  Protection  in  Programming  Languages; 
Communications  of  the  ACM,  vol,16,  no. 1  (January  1973) 
pp.  15-22, 

Morris  discusses  a  series  of  methods  of  protection 
from  hostile  programs.  It  is  noted  that  a  hostile 
program  can  be  either  from  a  competing  business  or 
agency,  or  it  can  just  as  easily  be  your  own  program 
which  contains  bugs.  Included  in  the  list  of  devices 
are  discussions  about  procedures  as  objects,  local 
objects,  type  protection,  memory  protection,  seals,  and 
trademarks.  For  memory  protection,  one  may  make 
reference  to  the  object  local  to  a  procedure  R.  In 
order  to  provide  outside  access,  the  programmer  can 
provide  reference  to  procedures  within  R,  Seals  are  a 
method  of  ensuring  that  a  programmer  has  taken  the 
correct  steps  prior  to  accessing  a  function,  and  aids 
in  localization  of  accesses. 

Falkoff70  1^11 


Falkoft,  A.D.;  Criteria  for  a  System  Design  Language; 
in  Buxton,  J.N.,  and  Randell,  B.  (ed.).  Software 
Engineering  Techniques  (1970)  pp. 88-93. 

Griffith72  1^11 

Griffith,  P.F.,  and  Henry,  R.M.;  An  Investigatory  Study 
into  Human  Problem  Solving  Capabilities  as  They  Relate 
to  Programmer  Efficiency;  SIGCPR  Bulletin,  vol.3,  no. 3 
(1972)  pp. 10-14. 

This  paper  is  detailed  description  of  a  research 
study  investigating  programer  efficiency  as  it  relates 
to  maintaining  varying  numbers  of  COBOL  data  processing 
programso  The  results  showed  that  greater  programmer 
efficiency  occurred  in  solving  3  ploblems  in  parallel 
than  solving  3  problems  sequentially.  The  sample  size 
was  18  subjects.  Hence  the  results  are  at  best 
marginally  significant.  These  results  seem  contrary  to 
other  results  noted  in  ’current  literature’,  but  did 
generate  much  enthusiasm  in  the  subjects  doing  the 
parallel  processing. 
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Ichbiah,  J.D,,  Rissen,  J.P.,  and  Heliard,  J.C. ;  The 
Two-Level  Approach  to  Data  Independent  Programming  in 

ceedings  ot 
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Wirth,  N.;  The  Programming  Language  Pascal; 
Inforraatica ,  vol.1,  no. 1  (1971)  pp. 35-63. 
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HcKeeaan,  W.M.,  Horning,  J.J.,  and  Wortman,  D.B.;  A 

Compiler _ Generator ;  Prentice-Hall,  N.J.  (1970)  pp.1- 

527. 


This  book  teaches  the  theory  and  practic:e  of 
compiler  construction.  A  System/360  realization  ot  the 
tools  is  presented  and  documented. 
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The  theory  section  gives  examples  of 
expressions,  declarations,  and  control 
emphasizing  the  relationships  between  reco 
attaching  meaning  to  program  parts, 
grounawork  is  laid  for  studying  formal  solu 
recognition  process  (parsing).  This  le 
discussion  of  automatically  generating  pa 
precedence  and  LB  (K)  techniques. 

The  practice  section  describes  both  t 
XPL  and  the  components  of  the  transla 
system.  The  components  XCOM  (the  XPL 
ANALYZER  (the  parser  generator),  and  S 
proto-compiler)  are  discussed  both  as 
building  compilers  and  examples  of  concep 
in  the  theory  section.  Finally,  the  i 
OS/360  is  described  in  the  appendices. 

Richards69  CB18,258 


t 

rans 

1 

ating 

s 

true 

t 

ures. 

gn 

izin 

g 

a  nd 

T 

heor 

e 

tical 

ti 

ons 

t 

o  the 

ad 

s  in 

t 

o  the 

rsers 

using 

he 

Ian 

guage 

to 

r  wt 

iting 

corapi 

ler)  , 

KE 

LETON 

(the 

t 

ools 

for 

ts 

desc 

1  ibed 

nterf ac 

e  to 

4*  10 


Richards,  M. ;  BCPL;  A  Tool  for  Compiler  a 
Writing;  Proceedings  of  the  SJCC,  volo34  (196 
566 . 

BCPL  is  a  simplification  of  CPL  (B 
developed  as  a  tool  for  writing  relative 
independent  systems  programs,  especially 
The  most  important  characteristic  of  the  1 
its  simple  semantic  structure  built  ar 
idealized  object  machine”  which  makes  BCPL 
machine  independent  and  easy  to  define  accura 
language  is  typeless  (the  only  data  object  b 
string  of  implementation-defined  length)  a 
wealth  of  constructs  to  control  flow  in 
fashion.  The  article  gives  an  interesting 
of  the  advantages  of  typeless  languages  an 
general  comments  on  design  of  languages  f 
implementation. 
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Nassi,  I.,  and  Schneiderman , 
for  Structured  Programming; 
no. 8  (Aug,  1973)  pp. 12-27. 


R;  Flowchart  Techniques 
SIGPLAN  Notices,  vol.8. 


With  the  acceptance  of  structured,  top-down, 
less  programming,  a  computational  model  is  needed 
prevents  unrestricted  transfers  of  control  and  ref 
the  control  structure  of  the  languages  suitabl 
structured  programming.  Some  advantages  of 
flowcharting  language  presented  are  that  the  see 
iterations  and  IF-THEN-ELSE  clauses  are  well  d€! 
and  visible,  that  the  scope  of  variables  is  obv 
and  that  arbitrary  transfers  of  control  are  iroposs 
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Wulf72fc 


10 


Wulf,  W.A,,  Hopkins,  M.E.,  Peterson,  H.W. ,  and  Waite, 
H.M.;  The  GOTO  Controversy:  Rebuttals  and  Discussion; 
SIGPLAN  Notices,  vol.  7,  no.  11  (November  1972) 
pp. 70-9 1 . 

Baker72b  CR25,352  2*10 

Baker,  H.A.;  How  to  Write  Systems;  Computer  Bulletin, 
vol. 1b,  no. 11  (Nov.  1972)  pp. 534-536. 

A  humorous  look  at  avoiding  all  real  problems, 
wilting  ’’friendly”  code,  and  muddling  through  the 

middle  of  the  project  on  the  way  from  the  end  to  the 
beginning.  The  module  decomposition  criterion  of 
Parnas  reappears  with  the  words  ’’put  the  code  least 
likely  to  succeed  off  by  itself.  Remember  that  you 
will  be  back  again”, 

Brophy70  Cfi20,231  2*10 


Brophy,  H.F.;  Improvin 
Australian  Computer  Jou 
pp. 66-70. 


bigg 

er 

nt 

he 

se 

of 

n 

of 

program  ini 
and  bette 
sugges  ts 
alread  y 
standard 


”The  purpose  of  t 
spotloght  on  to  the  hum 
relationship”.  In  this  a 
of  increasing 
building  bi 
improvement 
better 
imposition 
suggested  that  will  avoi 
solve  a  variation  of 
Brophy  suggests  the  use  o 
comments,  more  meanin 
documentation  cross  refer 
the  use  of  programrain 
utilizing  the  existinvj  to 
Finally,  standards  in 
documentation,  etc., 
communication  between  di 
to  improve  the  portabilit 


g  Programming  Perforaance; 
rnal,  vol. 2,  no. 2  (May  1970) 


his  paper  is  to  shift  the 
an  element  of  this  man/mcichine 
rticle,  Brophy  discusses  ways 
ng  performance  as  opposed  to 
r  machines.  To  achieve  an 
the  use  of  better  tools,  the 
available  tools,  and  the 
s.  Generalized  systems  are 
d  needless  reprogramming  to 
a  previously  solved  problem, 
t  decision  logic  tables,  more 
gful  variable  names,  better 
enced  with  the  program,  and 
g  teams  as  ways  of  better 
ols  of  software  development. 

language,  data  structures, 
are  proposed  to  improve 
fferent  programming  groups  and 
y  of  computer  software. 
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Morris,  J.B.;  Programming  by  Semantic  Refinement; 
SIGPLAK  Nccices,  vol. 8,  no. 9  (September  1973)  pp,120- 

122. 

Programmers  are  incapable  of  efficiently  producing 
reliable  programs  when  they  are  initially  confronted 
with  the  detail  of  the  final  program.  Semantic 
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refinement  is  offered  as  a  graduated  approach  from  an 
abstract  design  to  a  final  implementation.  This  is 
achieved  by  coding  and  debugging  the  system  in  a  series 
of  more  precise  languages,  the  last  of  which  is  a 
systems  implementation  language. 

flochmann73a  CR26,098  1*10 

Bochmann,  G.V.;  Multiple  Exits  from  a  Loop  without  a 
Goto;  Communications  of  the  ACM,  vol,  16,  no. 7  (July 
1973)  pp. 443-444. 

The  author  proposes  another  control  construct 
which  outside  of  the  body  of  a  loop  distinguishes 
between  normal  and  abnormal  termination  of  the  loop. 
This  appears  to  be  a  useful  control  structure 
extendable  to  the  searching  of  linked  lists. 

Kerpelmdn71  CB22,446  1*10 

Kerpelman,  C. ;  Clarification  of  FOHXKAN  Standards 
Second  Eeport;  Communications  of  the  ACM,  vol. 14,  no. 10 
(Oct.  1971)  pp. 628-642. 

A  revision  of  the  first  FORTBAN  standards  report 
is  presented  clarifying  ambiguities,  specifying 
definitions  omitted^  correcting  errors  and  discussing 
additions  and  extensions  to  the  standards  and  language. 
The  article  would  be  of  major  interest  only  to 
specialists  as  it  is  extremely  detailed  and  low  level 
however  it  serves  as  a  good  example  of  standardization 
and  documentation  problems  that  occur  in  any  attempt  at 
precise  language  definition.  Well  written  and  easily 
understood  because  of  its  nature  and  format. 

Poole69  CH19,612  1*10 

Poole,  P.Cc,  and  Waite,  W.M.;  Machine-Independent 
Software;  Proceedings  of  ACM  Second  Symposium  on 
Operating  Systems  Principles  (October  1969)  pp. 19-24. 

The  authors  advocate  that  machine  independence  be 
achieved  through  the  use  of  macros  rather  than 
compilers,  with  the  following  principal  advantages: 

1.  The  abstract  machine  may  be  flexibly  extended. 
There'’ s  no  need  to  design  a  ’"’complete”  language  at 
the  outset, 

2.  Optimization  may  be  tailored  to  specific  needs, 
through  modification  of  the  appropriate  macros. 

Kichards71  1*10 

Richards,  M. ;  The  Portability  of  the  BCPL  Compiler; 
Sof tware--Practice  and  Experience,  vol,  1,  no.  2 
(April/June  1971)  pp. 135-146. 
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Waite70b  CH20,135  1*10 

Waite,  W.M.;  The  Mobile  Programming  System:  STAGE2; 
Communications  of  the  ACM,  vol.  13,  no.  7  (July  1970) 
pp. 415-42 1 . 

Wulf71d  CH23,011  1*10 

Wulf,  W.A.,  Bussell,  D. B. ,  and  Habermann,  A.N.;  BLISS: 
A  Language  for  Systems  Programming;  Communications  of 
the  ACM,  vol,  14,  no,  12  (December  1971)  pp. 780-790. 

Dijkstra68c  13*9 

Dijkstra,  E.W.;  Co-operating  Sequential  Processes;  In 

Genuys,  F.  (ed,),  Proaiamming _ Academic 

Press  (1968)  pp. 43-112. 

The  use  of  semaphores  in  mutual  exclusion  and 
process  synchronization  is  discussed  and  techniques  for 
implementation  co-operation  among  parallel  processes 
are  examined  in  detail.  A  proof  of  correctness  is 
presented  for  the  message  interpreter  for  the  T.H.E, 
System  and  finally  the  Bankers  Algorithm  is  discussed 
as  a  means  of  preventing  deadlock. 

Saamet71  5*9 


Samraet,  J.E.;  A  Brief  Survey  of  Languages  Used  in 
Systems  Implementation;  SIGPLAM  Notices,  vol. 6,  no. 9 
(October  1971)  pp.1-19. 

A  good ,  concise  survey  which  touches  upon  the 
following  topics:  managerial  and  technical  reasons  for 
deciding  to  program  in  a  high-level  language;  some  of 
the  obvious  drawbacks  to  high-level  languages;  a  list 
of  "motherhood”  criteria  for  desirable  programming 
language  characteristics;  brief  and  not- too-usef ul 
descriptions  of;  ALGOL,  BLISS,  FOBTRAN,  IMP,  LRLIBAN, 
NELIAC,  Pascal,  and  PL/I.  Recommended,  and  it's  short. 
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Balzer;  R.M.;  Dataless  Programming;  Proceedings  of  the 
FJCC,  vol. 31  (1967)  pp. 535-544. 


In  order  to  provid 
data ,  a  data  structure 
is  not  to  result  in 
suggests  that  the  defi 
collection  of  objects  s 
of  the  operations  on 
the  Dataless  Programmin 
arrays,  lists  (sing 
structures,  composites 


e  for  a  change  in  operations  on 
must  be  highly  modifiable  if  it 
gross  inefficiencies.  Balzer 
nition  of  a  data  structure  for  a 
hould  be  specified  independently 
that  set.  He  therefore  proposes 
g  System  in  which  operations  on 
ly  or  doubly  linked),  rings, 
of  any  of  these,  and  even  user- 


t>4 


defined  collections  are  specified  identically.  The 
system  is  extensible;  the  routines  provided  include 
DELETE,  INSERT,  REPLACE,  ADD,  etc.,  allowing  for  set 
operations  such  as  FOR  EACH...  IN  THE  DOMAIN...  SUCH 
THAT. . . 

Maynard72  CK23,645  2*9 

Maynard,  J.;  Modular _Pro£irdmmintii  But terworths,  London 
(  1972)  pp.  1-100. 

The  observations  of  a  professional  programmer  on 
the  methods  of  modular  programming  and  its  benefits  in 
cost,  management  control,  flexibility,  and  program 
maintenance.  The  traditional  ’’monolithic”  program  is 
criticized  for  its  inherent  fragility  after  debugging, 
the  duplication  of  effort  involved,  and  the  mismatch  of 
programmer  talent  to  problem  that  usually  occurs.  A 
step-by-step  design,  decomposition,  and  implementation 
of  a  commercial  problem,  is  given  with  reference  to 
FORTRAN,  COBOL,  PL/I,  /360  assembler,  and  to  interface 
methods.  The  form  of  a  module  library  for  a  software 
procedure  is  discussed. 

Bergeron/ 1  6*8 


Bergeron,  R.D. 

,  Gannon,  J . D. , 

and  van  Dam, 

A. ;  Language 

for  Systems 

Development;  SIGPLAN  Notices, 

vol.6,  no. 9 

(October  1971) 

pp. 50-72. 

Constantine68 

CR14,  168 

2*8 

Constantine, 

L . L. ;  The 

Programming 

Profession , 

Programming 

Theory,  and 

Programming 

Education; 

Computers  and  Automation,  vol.17,  no. 2  (February  1968) 
pp. 14-19. 

The  classic  challenge  of  programming  has  been  that 
it  lacks  (1)  an  ordered  body  of  knowledge,  (2)  active 
interaction  between  the  practitioners  in  the  field  and 
that  body  of  knowledge  and  (3)  a  systematic  educational 
approach  for  imparting  that  knowledge  to  new  entrants 
in  the  field.  The  author  maintains  that  the  body  of 
knowledge  of  programming  exists,  but  not  in  an 
integrated  form.  Ho  proposes  two  theories  distinct 
from  each  other,  the  theory  of  programs  and  the  process 
theory  of  programming. 

Programs  consist  of  a  set  of  ordered  statements. 
There  is  a  structure  to  programs  determined  by  the 
relation  of  the  statements.  Programming  is  a  process 
that  involves  human  creativity.  Nevertheless,  it  is 
governed  by  rules,  perhaps  informal,  that  are  usually 
followed.  Much  more  is  known  about  programs  and 
programming  than  is  being  taught.  The  problem  is  that 
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Host  the  knowledge  is  gained  in  industry  and  most  of 
the  teaching  is  being  done  in  the  universities.  The 
author  maintains  that  a  lack  of  communication  between 
industry  and  the  universities  results  in  the  computer 
scientist  obtaining  an  incomplete  education.  He 
proposes  a  program  that  is  intended  to  remedy  this 
situation . 


Hopki ns7 1 
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Hopkins,  M.;  Problems  of  PL/I  for  Systems  Programming; 
SIGPLAN  Notices,  vol.  6,  no.  9  (1971)  pp. 89-91. 
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Aside  from  mentioning  t 
PL/I  constructs  and  th 
compiler,  Hopkins  point 
high-level  language  o 
systems  because  of  the 
source  code.  He  cla 
implemented  the  first  t 
is  often  not  put  to 
reluctance  to  tamper  wi 
great  paper,  but  at  two 


ion  by  an  IBM 
a  substanti 
he  many  defici 
e  difficulty  o 
s  out  that 
ften  leads  t 
understandabl 
iras  that  most 
ime,  and  that 
use  because 
th  a  "working” 
pages  it«s  wo 


project 
al  syste 
ent  or  i 
f  obtain 
prog  ramm 
o  more 
e  natur 
modu les 
experien 
of  th 
program 
rth  your 


hea 
m  in 
nef  f  i 
ing  a 
ing 
ef  f  i 
e  of 
are  p 
ce  9 
e  na 
H 

time 


Cheat ham72a 


CK25, 353 


d  of 
PL/I. 
cient 
good 
in  a 
cient 
the 
oorly 
ained 
tura  1 
ot  a 


1  +  8 


Cheatham,  T.E.;  The  Recent  Evolution  of  Programming 
Languages;  Proceedings  of  IFIP  Congress  1971,  vol.  1 
(1972)  pp. 298-313. 
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Definition; 
1973)  pp.50- 


odology  for 

implementing  operating  systems  and  other  related 
programs.  Starting  from  a  basic  language,  (machine 
independent  but  implemented  on  each  different  machine) 
a  hierarchy  ot  languages  is  described  each  of  which  is 
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written  in  the  previous  langudge.  Only  when 
implementing  primitives  for  parallel  processes  does  the 
real  machine  surface  again  presumably  for  interrupts, 
timing,  etc. 

Kjeldad369  CR22,795  1'^2 

Kjeldaas,  P.M.;  Security  in  Software;  lAG  Journal,  vol. 
2,  no.  2  (1969)  pp. 25-36. 

Brinch  nansen72 

Brinch  Hansen,  P.B.;  A  Comparison  of  Two  Synchronizing 
Concepts;  Acta  Inf orma tica,  vol.  1  (1972)  pp. 190-199. 

Conway63  CR5,024 

Conway,  M.E.;  Design  of  a  Seperable  Transition  Diagram 
Compiler;  Communications  of  the  ACM,  vol. 8  no. 7  (July 
1963)  pp. 396-408. 

Garwickbl 

Garwick,  J.V.;  The  Programming  of  Large  Logical 
Problems;  BIT,  vol.1,  no.  1  (1961)  pp. 21-26. 

By  "large  logical  problems"  Garwick  means  programs 
of  substantial  size  dealing  with  non-numerical 
problems.  He  states  that  the  usual  undisciplined 
approach  to  programming  is  unsatisfactory  and  makes 
suggestions  in  the  areas  of  planning,  testing,  and 
documentation  to  improve  the  programming  process.  His 
suggestions  for  planning  sound  like  the  beginnings  of 
the  ideas  of  stepwise  refinement  and  the  use  of  a 
programming  language  (Algol)  as  a  design  tool. 

Graham70 

Graham,  R,M.;  The  Use  of  High  Level  Languages  for 
Systems  Programming;  Proceedings  of  Invitational 
Workshop  on  Networks  of  Computers  (October  1970). 

Hansen71  CH22,792 

Hansen,  W.J.;  User  Engineering  Principles  for 
Interactive  Systems;  Proceedings  of  the  SJCC,  vol.  38 
(1971)  pp. 523-532. 

Hendry 7  1 

Hendry,  D.;  Benefits  For  User  and  Producer  of  an 
Engineering  Approach  to  Compiler  Design;  in  Hugo,  J.S. 

(ed.).  The _ loM£th _ Generation^  Infotech,  Ltd., 

Berkshire,  England  (1971)  pp. 299-312. 
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Henriksen,  J.O.,  and  Me 
Efficiency  in  Real-Ti 
of  the  SJCC,  vol.40  (19 
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Hoare,  C.A.R.;  Towa 
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(ed.) ,  Operating  System 
New  York  (197  2)  Pp.6'1-7 

Hoare73 

Hoare,  C.A.R.;  Hints  on 
ACM  Symposium  on 
Languages,  Boston  (1973 

Lock65  cm 

Lock,  K. ;  Structuring  P 
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vol.27,  part  1  (1965)  p 

The  paper  introd 
compilation,  a  scheme 
programs  in  accordance 
’•statement”  which 
modifications  to  his  so 
statement  level  wit 
program. 

Lyle7  1 

Lyle,  D.fl.;  A  Hierarchy 
Systems  Programming; 
(1971)  pp. 73-78. 
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Kills,  He ;  The  Complexity  of  Programs;  in  Hetzel, 

(ed.);  Ptogram^^ _ !l§§t_Methodsj;_  Pr eot ice-Hal  1,  Engl 

Cliffs  (1973)  pp. 225-238. 

Mills  begins  by  pointing  out  that,  ’*in  com 
programming,  we  have  not  yet  discovered  that  compl 
has  weight'*.  He  goes  on  to  discuss  the  rol 
structured  programming,  the  complexity  of  understa 
programs  and  proving  programs  correct.  He  defines 
types  of  programs:  rational  and  natural,  which  ref 
the  knowledge  available  about  the  internal  mechani 
the  program.  A  rational  program  is  one  whose  int 
mechanism  is  transparent  to  some  people;  a  na 
program  is  one  whose  internal  mechanism  is  known 
one.  Programs  begin  in  the  rational  state 
eventually  pass  on  to  the  natural  state  where  they 
become  obsolete.  His  objective  in  measuring 
controlling  complexity  is  to  keep  a  program  rat 
for  as  long  as  possible,  and  certainly  much  longer 
at  present,  before  the  inevitable  rot  sets  in. 
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Naur,  P. ;  Algol  Programming; 
Algol  Style;  FIT,  vol.3,  no. 
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3  (1963)  pp. 204-205. 
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N[eufflann69 


Cd^9,622 


Neumann,  P.G, ;  The  Role  of  Motherhood  on 
Systems  Programming;  Proceedings  Second 
on  Operating  Systems  Principles  (Oct.  1 
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Newman68 


CR15,982 


Newman,  W.M.;  A  System  for  Interactive  Graphical 
Programming;  Proceedings  of  the  FJCC,  vol.  32  (1968) 
pp. 47-54. 

Roberts67  CR17,857 


Roberts,  K.V.;  The  Readability  of  Computer 
Computer  Bulletin,  vol. 10,  no. 4  (March  1967) 


Programs; 
pp. 17-24. 


Ross7  0 


CR21,883 


Ross,  D.T.;  Uniform  Referents:  An  Essential 
for  a  Software  Engineering  Language;  In  Tou, 
Soft  ware,.  Engineering^  vol.l.  Academic  Press, 
(1970)  pp. 91-101. 
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ke,  J.;  PL/I  Subsets  for  Software  Writing; 
otices,  volc6,  no. 4  (1971)  pp. 16-22. 

article  discusses  the  possibility  of  extending 
of  the  PL/I  language  for  use  in  compiler  and 
system  writing.  The  primary  aims  of  high 
languages  are  machine  independence  and 
ty.  This  is  contrasted  with  the  need  of  the 
of  software  to  have  full  control  over  all  the 
of  the  machine.  Therefore  the  solution  of  the 
is  not  a  general  high  level  language,  but  one 
ailored  to  the  given  computer,  while  at  the 
retaining  some  of  the  good  features  of  a  high 
guage.  The  author  suggests  a  subset  of  PL/I 
extensions  which  he  describes  in  the  article, 
uld  become  a  good  language  for  software 
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Wirth68  Cai4,506 

Wirth,  N. ;  PL360,  A  Programming  Language  for  the  360 
Computers;  Journal  of  the  ACM,  vol.  15,  no.  1 
(January  1968)  pp. 37-74. 
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Yi_Cor  rGct  nessj^_  val  ida  tionx_dnd_debucj^in^ 

DijkstLd71d  5*17 

Dijkstra,  E.W.;  ConceLn  For  Correctness  as  a  Guiding 
Principle  for  Program  Composition;  in  Hugo,  J.S,  (ed) , 

The Fourth t  ion^  Infotech,  Ltd.,  Berkshire, 

England  (1971)  pp. 357-367. 

In  this  state  of  the  art  report,  Dijkstra  reviews 
the  current  state  in  the  programraing  world,  and  notes 
the  unfortunate  situation  with  respect  to  programming 
and  debugging  practices.  As  an  alternative  to  this,  he 
proposes  and  presents  a  strong  argument  for  a 
structural  approach  to  the  construction  of 
’•intellectually  manageable”  programs  which  yields 
correctness  proofs  with  much  less  effort. 

Dijkstra68d  CK16,717  7*16 

Dijkstra,  E.W.;  A  Constructive  Approach  to  the  Problem 
of  Program  Correctness;  BIT,  vol.8,  no.  3  (1968) 
pp.  174-186. 

Dijkstra  states  that  there  are  two  ways  to 
establish  the  correctness  of  a  program.  As  an 
alternative  to  a  posteriori  techniques  this  paper 
proposes  that  a  priori  correct  programs  can  be  produced 
by  controlling  the  process  of  program  generation  in  a 
manner  that  is  demonstrated  on  a  simple  problem. 

Floyd72  CS25,232  7*16 

Floyd,  R.H.;  Toward  Interactive  Design  of  Correct 
Programs;  Proceedings  of  IFIP  Congress  71,  vol.  1 
(1972)  pp.7-10. 

An  imagined  interaction  between  a  computer 
programmer  and  his  machine  is  described,  in  which  the 
computer  checks  the  program  for  consistency  with  the 
progtammer ’ s  stated  intentions,  and  proves  the  logical 
or  semantic  correctness  of  the  program  at  various 


levels. 

London70c 

CK21,040 

5*  16 

London , 

R.L.;  Proving  Programs  are  Correct: 

Some 

Techniques  and  Examples;  BIT,  vol.  10,  no.  2  (1970) 

pp.  168-  182. 

The  advantages  and  feasibility  of  proving  programs 
correct  are  demonstrated.  Among  the  advantages 

mentioned  are  that  the  discipline  of  the  proof 
technique  provides  the  programmer  with  a  method  or 
systematically  searching  for  errors  and  that  the 
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Burstall69 


CR17,495 


2*15 


Durstall,  H.fl.;  Proving  Properties  of  Programs  by 
Structural  Induction;  The  Computer  Journal,  vol.12, 
no. 1  (February  1969)  pp. 41-48. 


This  paper  presents  the  technique  of  structural 
induction  for  proving  the  validity  of  the  type  of 
programs  where  repetition  is  accomplished  by  recursion, 
and  jumps  and  assignment  are  avoided.  The  author 
considers  the  technique  of  structural  induction  a  very 
powerful  tool  which  is  easy  to  use  and  gives  a  clear 
explanation  in  ordinary  mathematical  terms  of  why  a 
program  works  as  it  does.  The  technique  depends  on  the 
structure  of  the  data  manipulated  by  the  program,  and 
the  objective  is  to  prove  rot  just  that  the  program 
works  for  specimen  input  data  but  that  it  will  work  in 
general  for  any  input  data. 


The  author  feels  that  the  first  step  should  be  to 
devise  methods  of  proof  of  validity  of  non-trivial 
programs  in  a  comprehensible  manner.  The  reasoning 
might  later  be  formalized  to  a  point  where  it  can  be 
performed  by  a  computer  to  provide  mechanized  debugging 
aids. 


The  fflain_aim  of  the  paper  is  to  suggest  some 
syntactic  devices  for  writing  programs  in  a  way  which 
facilitates  the  derivation  of  proofs  by  structural 
induction.  The  form  of  these  proofs  would  then  be 
similar  to  that  of  the  corresponding  programs.  The 
author  believes  that  the  discipline  of  stating  theorems 
and  devising  proofs  will  greatly  improve  programming 
education  and  practice, 

Elspas71  2*15 


Elspas,  B,,  Green,  M.W.  ,  and  Levitt,  K.N.;  Software 
Reliability;  Computer,  vol.4,  no. 1  (January/  February 
1971)  pp. 21-27, 

In  this  article  we  have  an  overview  of  the  general 
streams  of  software  reliability.  The  first  area 
discussed  is  that  of  language  design  where  the  authors 
present  a  case  .  for  a  wide  range  of  program  checking 
devices  which  would  enforce  discipline  on  a  program. 
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The  second  area  considered  is  that  of  semantic 
checking,  where  is  a  case  is  presented  for  checking  the 
semantics  of  code  via  automatic  path  testing.  Lastly, 
the  authors  take  a  brief  look  at  automatic  program 
verification.  Some  informal  proof  techniques  are 
examined  in  some  detail  with  a  proof  for  a  small  piece 
of  code  being  provided.  A  brief  summary  is  given  of 
the  more  formal  proof  techniques. 

Rustin71  CR22,801  1*15 

Rustin,  H.  {ed)  ;  bsbuqqinq _ Techniques _ in _ habile 

Prentice-Hall,  N.J.  (1971)  pp, 1-141. 

Snowdon70  1*15 

Snowdon,  H.  ;  Possible  Computer  Assistance  in  Program 
Structuring  and  Correctness;  University  of  Newcastle 
Upon  Tyne,  Computing  Laboratory  (1970). 

Snowdon72  9*14 

Snowdon,  R.A.;  PEARL:  An  Interactive  System  for  the 
Preparation  and  Validation  of  Structured  Programs; 
SIGPLAN  Notices,  vol.7,  no.  3  (Karch  1972)  pp.9-26. 

The  author  describes  a  partially  implemented 
interactive  system  whose  purpose  is  to  assist  the 
programmer  in  writing  structured  programs.  Provisions 
exist  in  PEARL  for  some  assistance  towards  program 
correctness.  The  system  restricts  its  attention  to 
small,  sequential  programs  designed  by  a  single 
programmer . 

Initially,  an  ideal  ’'machine”  is  described,  both 
by  the  specification  of  its  data  types  and  operations, 
and  by  a  program  written  for  that  machine.  The 
introduction  of  further  machines  (and  programs  for 
them)  serves  to  refine  the  meaning  of  previously 
introduced  programs  and  constructs.  Conditions  may  be 
given  to  operations  in  order  to  aid  in  ensuring  program 
correctness  for  a  particular  machine. 

The  system  has  various  facilities  for  program 
editing,  and  incompletely  specified  programs  can  be 
run,  as  well  as  compiled,  with  PEARL  requesting 
assistance  upon  encountering  an  operation  which  has  not 
been  fully  explained. 

King7 1b  7*14 

King,  J. ;  A  Verifying  Compiler;  in  Rustin,  R.(ed.), 

Debugging _ T®chnigues _ in_I;^i;ae_Systems^  Prentice- Hall , 

Inc.  (1971)  pp. 17-40. 
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Randell,  B.;  Highly  Reliable  Computing  Systems; 
University  of  Newcastle  upon  Tyne,  Technical  Report  20 
(1971)  pp.1-39. 

This  report  discusses  the  needs  for  and  the 
problems  of  achieving  high  reliability  from  complex 
computing  systems.  System  performance  and  system 
reliability  are  both  commodities  for  which  the  user  has 
to  pay.  Usually,  they  are  inversely  related  (e.g., 
high  system  reliability  usually  means  a  loss  in  system 
performance) .  Operating  systems  are  intended  to  extend 
the  reliability  of  and  to  cope  with  the  unreliability 
of  the  hardware.  However,  it  may  turn  out  that  the 
operating  system  presents  a  bigger  reliability  pioblero 
than  the  hardware.  In  a  computing  system,  it  should  be 
the  responsibility  of  the  hardware  to  detect  hardware 
errors  and  the  responsibility  of  the  operating  system 
to  cope  with  and  isolate  these  errors. 
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ot  attempting  to  minimize  the  extent  to  which  reliance 
is  put  on  the  correct  and  continuing  functioning  of  the 
system”. 
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London,  R.L.;  Bibliography  on  Proving  the  Correctnes  of 
Computer  Programs  -  Addition  No.  1;  University  of 
Wisconsin,  Department  of  Computer  Science,  no.  104 
(December  1970)  pp, 1-8. 

Smith72a  CH24,6B2  2^14 

Smith,  J.M.;  Proof  and  Validation  of  Program 
Correctness;  The  Computer  Journal,  vol.15,  no, 2  (May 
1972)  pp. 130-131. 

The  author  points  out  that  ever  since  1962  when 
McCarthy  raised  the  concept  that  programs  should  be 
proved  correct  rather  than  merely  verified, 
considerable  effort  has  been  devoted  to  the  study  of 
techniques  for  producing  such  proofs.  So  far  little 
progress  has  been  made  although  this  effort  has  lead  to 
advances  in  programming  languages,  theory  of 
algorithms,  and  system  theory. 


The  author  proposes  that  it  may  not  be  possible  to 
prove  the  correctness  of  practical  programs  rigorously 
enough  to  satisfy  the  definition  of  program  correctness 
as  stated  by  Manna  in-  1969,  The  basis  of  this 
definition  is  the  concept  of  a  program  yielding  the 
’desired  result’.  In  general  it  is  not  always  possible 
to  define  this  desired  result  and  the  author  proposes 
other  approaches  to  program  validation  by  which  program 
errors  can  be  reduced  and  the  confidence  level  of  a 
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Hoane,  C.A.H.  ;  Proof  of  a  Program:  FIND;  Comraunica tions 
of  the  ACM,  vol.14,  no. 1  (Jan,  1971)  pp. 39-45, 

An  iro^ortant  non-trivial  example  of  concurrent 
program  construction  and  proof  of  correctness.  Hoare 
mentions  some  disadvantages  and  weaknesses  to  this 
approach,  but  he  obviously  feels  that  such  formal 
proofs  are  extremely  important  and  that  eventually 
computer  assistance  may  be  possible. 
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Blair,  J, ;  Extendable  non-Interacti ve 
Rustin,  R,(edo)i,  pebugg  ing  _  Techni  jues__  in 
Prentice-Hall  (1971)  pp. 93-115, 
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Z.,  and  Waldingert,  RoJ.;  Toward 
Synthesis;  Communications  of  the  ACM, 
(March  1971)  pp.  151-165. 
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of  Bugs;  in  Rustin,  R.  (ed.). 
Large  Systems,  Prentice-Hall 


(1971)  pp . 1- 1 6. 

In  this  article,  a  classification  of  bugs  is 
outlined  including  type,  frequency,  and  habitat.  The 
’’process  of  bug  extermination”  is  reviewed,  and 
suggestions  tor  improvement  of  debugging  tools  is 
discussed.  Structure  of  programs  and  proofs  of  program 
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correctness  are  examined.  The  d; 
space  in  the  debugging  process,  as 
debugging  language  are  considered. 
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Bernstein,  W.A.,  and  Owens,  J.;  Debugging  in  a 
Sharing  Environment;  Proceedings  of  the  FJCC, 
(  1968)  pp.7-m. 


4*12 

Tiae- 
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This  paper  provides  a  good  examination  of 
conventional  debugging  tools,  and  appraises  their 
adequacy  in  view  of  programming  advances.  It  then 
discusses  the  characteristics  of  a  support  system  that 
meets  the  debugging  and  program  modification  needs  of  a 
time-sharing  system. 
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Floyd,  R.W.;  Assigning  Meanings  to  Programs; 
Proceedings  of  a  Symposia  in  Applied  Mathematics, 
American  Mathematical  Society,  vol.  19  (1967)  pp.19- 
32. 
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Algorithms  by  General 
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Floyd,  R.W.;  The  Verifying  Compiler;  Carnegie-Mellon 
University,  Department  of  Computer  Science  (December 
1967) . 
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Grahaffl,  S.L.,  and  Rhodes,  S.P,  ;  Practical  Syntactic 
Error  Recovery  in  Compilers;  ACM  Syaposium  on 
Principles  ot  Program  mi ng  Languages,  Boston,  Mass, 
(Oct.  1973)  pp, 62-58, 


The  artic' 
and  recovery 


e  pr 
to 


opos 

”ma 


es  a  method  of 
ximize  the  n 


det 

ec ted" 

and 

”m 

ini 

mi 

ze 

the 

an 

error 

when 

t  h 

ere 

i 

s 

none" 

t  hu 

s  to  m 

inim 

ize 

th 

e 

nu 

fflber 

pro 

gram 

with 

sy 

nta 

X 

er 

rors. 

two 

parts 

:  a 

con 

den 

sa 

ti 

on  ph 

to 

locally  re 

cov 

er 

f  r 

om 

t  he 

and 

a  cor 

rect 

ion 

ph 

ase 

which 

error  detection 
umbers  of  errors 
times  it  reports 
m  of  the  system  is 
eeded  to  debug  a 
hod  is  composed  of 
the  system  tries 
continue  parsing, 
to  correct  the 


error . 


Rain?  3 


CR25, 204 


9*1 1 


Rain,  M, ;  Two  Unusual  Methods  for  Debugging  System 
Software;  Software-Practice  and  Experience,  vol.3,  no.  1 
(Jan. -Mar,  1973)  pp. 61-63, 
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Kulsrud,  H,E.;  Extending  the  Interactive  Debugging 
System  Helper;  in  Rustin,  Ro(ed,)ff  Debugging_Techn igues 
i2_i®13®_Slstems^  Prentice-Hall,  Inc.  (1971)  pp. 77-91. 

Helper  is  an  interactive  extensible  debugging 
system  directed  to  the  problems  of  debugging  at  the 
machine  language  level.  Although  basically 
interactive.  Helper  can  be  used  in  a  batch  manner.  It 
accomplishes  complete  program  analysis  by  simulation  of 
instructions.  Helper's  extensibility  "provides  a  means 
for  checking  out  new  ideas  in  debugging”,  and  "allows 
for  continual  upgrading  of  the  debugging  tools”. 
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Ogdin,  J.L.;  Improving 
Datamation,  vol. 19,  no, 1  (Jan 
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Software  Reliability; 
1973)  pp. 49-52. 
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This  paper  tries  to  develop  ways  for  improving 
software  reliability,  using  modular  programming.  The 
author  first  makes  a  general  comparison  of  a  program  to 
a  mathematical  function,  showing  the  many  similarities 
that  exist,  and  then  narrows  this  comparison  to  tasks 
and  modules. 


In  an  effort  to  provide  for  more  reliable 
software,  the  author  discusses  several  relevant  areas, 
such  as  where  the  decisions  should  be  made  in 
hierarchies  of  tasks  and  the  problem  of  changing 
specif ica tions  for  written  modules.  When  the  modules 
are  redefined,  they  should  be  renamed.  Finally, 
program  bugs  are  classified  and  then  reasons  and 
solutions  are  given  for  them. 
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Good,  D.I.;  Toward  a  Man  -  Machine  System  for  Proving 
Program  Correctness;  Ph.  D.  Thesis,  University  of 
Wisconsin,  Department  of  Computer  Science  (1970). 


The  problem  considered  is  the  realization  of  a 
computerized  program-proving  system  that  is  applicable 
to  real  computer  programs.  The  inputs  to  the  system 
are  a  program  and  the  specifications  this  program  must 
meet  in  order  to  be  correct.  If  the  program  actually 
is  correct,  then  the  system  should  either  prove  that 
the  program  is  correct,  or  at  least  provide  assistance 
so  that  proving  correctness  becomes  a  feasible  task  for 
a  human.  If  the  program  is  not  correct,  the  system 
should  assist  in  locating  errors  in  the  program.  The 
total  question  of  the  practical  realization  of  proving 
the  correctness  of  programs  is  considered  from  three 
levels.  At  the  first  level,  a  simple  model  that  can 
describe  a  significant  class  of  real  programs  is 
developed.  Based  on  this  model,  the  idea  of  a  result 
of  a  program  is  formalized.  The  second  level  is  a 
general  method  for  proving  program  results,  the 
inductive  assertion  method.  The  third  level  is  the 
realization  of  man-machine,  interactive  program  proving 
system  through  a  partial  automation  of  the  inductive 
assertion  method. 
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Handell,  B. ;  Operating  Systems:  The  Problems  of 
Performance  and  Reliability;  Proceedings  of  IFIP 
Congress  71,  vol.  1  (1972)  pp. 281-290. 
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Elspas,  B.,  Levitt,  K.N,,  Waldinger,  R.J.,  and  Wakeman, 
A.;  An  Assessraent  of  Techniques  for  Proving  Program 
Correctness;  Computing  Surveys,  vol,4,  no. 2  (June  1972) 
pp. 97-  1U7 . 

LaFrance71 


LaFiance,  J.E.;  Syntax-directed  Error  Recovery 
Compilers;  FL;.  D.  Thesis,  University  of  Illino 
U t band-champaign ^  Department  of  Computer  Science  ( 

pp.  1-162. 

This  thesis  presents  a  system  of  automatic 
recovery  for  syntax  directed  parsing  algorithms 
is  based  solely  on  the  syntax  of  the  language, 
method  is  not  only  automatic,  requiring  no  addit 
effort  from  the  language  designer  beyond  the  synt 
specification  of  his  language,  but  it  also  is  much 
effective  than  most  hand  written  systems.  In  a  se 
programs  run  on  four  different  compilers  constr 
using  this  system,  only  six  out  of  140  errors 
missed  and  92  out  of  the  134  errors  detected 
described  to  the  programaer  exactly.  In  only  nin 
the  134  detected  errors  was  the  message  about  the 
apt  to  be  confusing. 
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Sa tterth wa ite ,  E. ;  Debugging 
Languages;  Software  -  Practice 
no.  3  (July  -  September  1972) 


Tools  for  High-Level 
and  Experience,  voi .  2, 
pp,  197-217. 
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Allen,  C.D.;  The  Application  of  Formal  Logic  to 
Programs  and  Programming;  IBM  Systems  Journal,  vol.10, 
no.  1  (Jan,  1971)  'pp„2“38. 

A  hierarchical  application  of  first-order 
predicate  calculus  is  a  practical  solution  for  proving 
the  correctness  of  programs.  Allen  first  gives  a  brief 
introduction  to  formal  logic,  and  then  develops  the 
results  of  Manna  and  Ashcroft  on  an  elementary  level. 
Finally  he  presents  some  examples  and  theories  of  his 
own  as  well  as  some  applications  of  the  proof 
techniques . 

Balzer69  CR16,065  1*10 

Balzer,  R.M.;  EXDAMS  -  Extendable  Debugging  and 
Monitoring  System;  Proceedings  of  the  SJCC,  vol.  34 
(1969)  pp. 567-580. 
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Kahn,  .3.;  An  Approach  to  Sy;-3tem  Correctness; 
pLoceeclinjs  ot  the  Third  ACM  symposium  on  Operati  ikj 
Systeins  Piinciples  (Oct.  1971)  pp.dG-94. 

Dealing  with  sycti-^ins  ot  a  rinito  number  oi 
processes,  the  author  discusses  several  approaches  to 
descriLiny  a  system  and  proving  its  coriectnoss.  As 
usual,  success  is  claimed  for  the  chosen  methods  when 
they  are  shown  cajiablta  of  dealincj  with  Di  jkstrd-esgiie 
examples;  in  this  case  semaphores  and  the  hungry 
philosophors/slippery  spaghetti  problem. 

Hedrick7()  1*9 

Hedrick,  c , d .  ;  User  trror  Analysis  and  Automatic 
Correction  tor  Compiling;  Ph.  E,  Thesis,  Iowa  Stat(' 
University,  Department  of  Computer  Science  (1  970)  pp.  1- 
2  0o. 

This  thesis  presents  a  basic  theory  for  the 
development  of  an  error  corrector.  The  use  of  this 
theory  should  provide  one  additional  debugging  tool  for 
the  high-level  language  programmer.  Techniques  are 
developed  for  automatically  determining  the  existence 
of  errors,  locating  errors,  and  choosing  the  most 
probable  correction. 

An  error  corrector  was  developed  for  a  selected 
subset  of  high-level  language  programs  wiiich  use  the 
WAifOR  compiler.  The  corrector  was  implemented  using 
the  following  steps: 

1.  A  random  sample  of  programs  which  use  the  WAT  FOR 
compiler  was  obtained. 

2.  Statistics  were  gathered  so  that  programs  could  be 
described  in  terms  of  the  errors  that  programmers 
make , 

d.  Correction  algorithms  were  developed  tor  the  most 
common  errors. 

4.  The  algorithms  were  coded  as  correction  programs, 

5.  The  correction  program  was  applied  to  the  WATFOr  job 
stream . 

vJonssoiibB  CK16,001  1*9 

Jonsson,  S.I.;  On-line  Program  Debugging;  HIT,  vol.  d, 
no.  2  (1968)  pp. 122-127. 

Dijkstrabbb  CR9,023  8*8 

Dijkstra,  E.W.;  Solution  of  a  Problem  in  Concurrent 
Programming  Control;  Communications  of  the  ACM,  vol. 8, 
no. 9  (1965)  pp.569. 
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This  paper  presents  an  algorithm  which  ensures 
that  at  any  moment  one  and  only  one  of  a  number  of 
mainly  independent  sequential  cyclic  processes  with 
restricted  means  of  communications  with  each  other  is 
engaged  in  the  ’’critical  section”  of  its  cycle. 

Vander  Noot71  4*8 

Vander  Noot,  T.J-;  System  Testing...  A  Taboo  Subject; 
Datamation,  vol.17,  no. 21  (Nov.  1971). 

This  article  suggests  how  the  programmer  should 
test  his  program  to  detect  bugs  and  how  the  customer 
should  test  a  received  product. 

King7 la  3^8 

King,  J.C.;  Proving  Programs  to  be  Correct;  IEEE 
Transactions  on  Computers,  vol.C-20,  no. 1  1  (Nov.  1971) 
pp. 1331-1336. 

Kulsrud69  Cal9,805  2*8 

Kulsrud,  H.E.;  HELPER:  An  Interactive  Extensible 
Debugging  System;  Proceedings  of  ACM  Second  Symposium 
on  Operating  Systems  Principles  (October  1969)  pp.105- 
111, 

HELPER  is  a  semi-sophisticated  graphical  on-line 
debugging  system  intended  for  use  with  low-level 
languages.  A  command  language  compiler  is  utilized 
with  access  to  problem  program  symbol- tables  and  other 
data.  Little  mention  is  made  of  the  effect  of  this 
system  on  programming  habits  except  to  state  that  its 
use  is  somehow  addictive.  That  is  not  necessarily  a 
recommendation. 

Waldinger69  Cfi20,483  2*8 

Waldinger,  R.J.,  and  Lee,  R.C.T.;  PROW:  A  Step  Toward 
Automatic  Program  Writing;  Proceedings  of  the 
International  Joint  Conference  on  Artificial 
Intelligence  (1969)  pp. 241-252. 

The  program  PROW,  is  described  which  accepts  the 
specification  of  an  algorithm  expressed  in  the  language 
of  the  first  order  predicate  calculus  and  produces  a 
LISP  program  which  implements  this  algorithm.  Since 
theorem  proving  techniques  are  used  to  construct  these 
programs,  they  are  necessarily  free  of  logical  errors. 
The  authors  see  this  system  as  a  first  step  towards  the 
goal  of  freeing  programmers  from  the  task  of  learning 
many  different  programming  languages. 
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The  application  of  PROW  to  question  -  answering 
systems  and  to  the  generation  of  programs  in  languages 
other  than  LISP  is  discussed. 
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Brady,  P, ;  Writing  an  Online  Debugging  Program  for  the 
Experienced  User;  Communications  of  the  ACM,  vol.11, 
no. 6  (1968)  pp. 423-427. 
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Evans,  T.G.,  and  Carley,  D.L.;  Debug  -  an  Extension  to 
Current  Online  Debugging  Techniques;  Communications  of 
the  ACM,  vcl.S^,  nOo5  (196b)  pp.  321-326. 
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Grishman,  R„ ;  The  Debugging  System  AIDS;  Proceedings  of 
the  SJCC,  voi.  36  (1970)  pp. 59-64. 

Supnik71  CR23,017  1*8 

Supnik,  RwMc,;  Debugging  Under  Simulation;  in  Rustin, 

S.  (ed.),  Debuggino _ Techniques _ in _ Large _ Systeras^^ 

Prentice- Hall  (1971)  pp. 117-136. 

Van  Horri68  CR15,580  1*8 

Van  Horn,  C.C.;  Three  Criteria  for  Designing  Computing 
Systems  to  Facilitate  Debugging  ;  Communications  of  the 
ACM,  vol.  11,  no.  b  (May  1968)  pp. 360-365. 

Ver  Steeg64  CK6,9b0  1*8 


Ver  Steeg,  R.L.;  TALK  -  A  High-Level  Source  Language 
Debugging  Technique  with  Real-Time  Data  Extraction; 
Communications  of  the  ACM,  vol.  7,  no.  7  (July  1964) 
pp. 418-419. 

Baeck.eL68  CR16,002  1*7 

Baecker,  R.M.;  Experiments  in  On-Line  Graphical 
Debugging:  The  Interrogation  of  Complex  Data 
Structures;  Proceedings  of  the  Hawaii  International 
Conference  on  Systems  Sciences  (1968)  pp.  128-129. 

A  study  of  complex  data  structure  interrogation 
using  display  screens  to  help  debug  graphical  language 
programs  with  the  focus  on  keeping  the  level  of 
interrogation  suitably  high  to  allow  sophisticated 
search-oriented  questioning  in  keeping  with  the  level 
of  the  graphical  languages  and  the  data  they  structure. 
For  its  time  the  article  presents  an  advanced  attempt 
at  raising  the  level  of  interactive  debugging  aids  to  a 
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level  well-suited  to  the  source  language  used.  It  is 
also  one  of  the  first  uses  of  video  tracing  of  data  to 
give  the  interrogator  a  data  history  during  his 
questioning, 

Clint  72 

Clint,  M. ,  and  Hoare,  C.A.fi.;  Prograa  Proving:  Jumps 
and  Functions;  Acta  Inforraatica,  vol.  1,  no.  3  (1972) 

pp. 214-224. 

Evans66 

Evans,  T.G.,  and  Parley,  D.L.;  On-line  Debugging 
Techniques:  A  Survey;  Proceedings  of  the  FJCC,  vol.  29 
(1966)  pp. 37-50. 

Fong73 

Fong,  E.N.;  Improving  Compiler  Diagnostics;  Datamation, 
vol.  19,  no.  4  (April  1973)  pp. 84-86. 

Most  of  a  programmer's  effort  in  program 
development  is  spent  in  debugging.  The  author  suggests 
some  debugging  and  monitoring  facilities.  These  are 
divided  into  three  different  groups.  Compile-time 
checks  include  syntax  checking,  cross  reference 
listing,  modularity,  paragraphing,  and  static  control 
concordance.  Formal  and  actual  argument  checks  and 
static  subroutine  analysis  can  be  performed  at 
link/load  time.  Execut ion- ti me  checks  include  dynamic 
traces  of  subroutine  calls,  flow  of  control,  and 
variables  in  addition  to  snapshot  dumps  and  address 
checking . 

Gould71  CR22,292 

Gould,  J.S,;  On  Automatic  Testing  of  On  Line  Heal  Time 
Systems;  Proceedings  of  the  SJCC,  vol,  38  (1971) 
pp. 477-484, 

Hanfora70  CH21,221 

Hanford,  K.V,;  Automatic  Generation  of  Test  Cases;  IBM 
Systems  Journal  vol, 9,  no. 4  (1970)  pp. 242-257. 

Hanford  describes  his  ’’syntax  machine”.  This  is  a 
program,  which  he  has  implemented  on  S/360,  which 
produces  programs  which  are  syntactically  correct  (but 
meaningless).  These  programs,  which  can  be  used  for 
testing  compilers,  may  be  produced  either  pseudo- 
randomly,  or  exhaustively.  He  introduces  what  he  calls 
a  ”dynaraic  grammar”  which  allows  the  user  to  provide 
for  the  context  sensitivity  (e.g.,  variables  must  be 
declared)  of  the  language  being  generated. 
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Josephs69  Ct<1By8B9 

Josephs, W . Ho c  An  On-line  Mach 
OS/960;  Proceedings  of  the 
pp. 179-186. 

Larapson7 1 

Larapson,  On  Reliable 

Systems;  in  Hago^,  J^S.  (ed 
Infotech,  Ltd.,  Berkshire, 
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Landyj,  B.  ,  and  Needham,  R. 
Techniques  used  in  the  De 
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Lanzarone,  G.A,;  Proof  of 
Review;  Honeywell  Computer  J 
pp. 38-42. 

Lanzarone  gives  a  concis 
the  art  of  program  correctn 
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London7 1 


London,  R.L.;  iixperience  with 
Proving  Programs  Correct; 
Syffiposiuro  on  Seniantics  of 
Springer- Verlag ,  Berlin  (1971) 

The  author  discusses  and 
inductive  assertion  method  of 
He  gives  examples  of  both  the 


Inductive  Assertions  for 
In  Engler,  E.  (ed) ; 
Algorithmic  Languages; 
pp. 236-251 . 

gives  examples  of  the 
proving  programs  correct, 
forward  accumulation  and 


backward  substitution  methods  of  verifying  assertions 
using  a  particular  type  of  assertion  representation. 
He  also  looks  at 
correctness  provers. 


two  attempts  to  develop  automatic 


McCar thy67 


McCarthy,  J.,  and  Painter, 
Compiler  for  Arithmetic 
Aspects  of  Computer  Science 


d.A,.;  Correctness  of  a 
Expressions;  Mathematical 
(1967)  pp. 33-41. 


Poola7  3 


Pcole,  P.C.;  Debugging  and 
(ed.).  Advanced  Course 
Springer- Verlag ,  New  ^ork 


Testing;  in  Bauer,  F.L. 
on  Software  Engineering, 
(1973)  pp. 278-318. 


Prokop73 


CK25,529 


Piokop,  J.S.;  On  Proving  the  Correctness  of  Computer 
Programs;  in  Hetzel,  W.C.  (ed.);  Program  Test , Methods; 
Prentice-Hall,  Englewood  Cliffs  (1973)  pp, 29-37. 
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Stockham,  T.G.;  Some  Methods  of  Graphical  Debugging; 
Proceedings  of  the  IBM  Scientiiic  Computing  Symposium 
on  Man-Machine  Coramanicat ion  (1966)  pp. 57-68. 
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Wood69  CK18,331 

Wood,  D.  ;  A  Proof  of  Hamblin's  Algorithm  for 
Translation  of  Arithmetic  Expressions  from  Infix  to 
Postfix  Form;  BIT,  voi.  9,  no.  1  (1969)  pp. 59-68. 
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ZurcherBB  CH17,922  2«15 

Zurchers,  and  Randell^  B.  ;  Iterative  Multilevel 
Modeling  -  A  Methodology  for  Computer  System  Design; 
Proceedings  of  IFIP  Congress  1968  (196B)  pp,13B-142. 

The  authors  describe  a  philosophical  and  practical 
approach  to  the  design  of  complex  software  systems.  In 
contrast  to  Dijkstra®s  structured  programming^  the 
method  proceeds  in  a  strictly  top-down  manner;  as 
opposed  to  Weiderfflan“s  ’'“iraplementa  tion  cum  model”, 
Zurcher  and  Randell  propose  basically  a  system  model 
which  prodxices  a  working  iapleaenta tion  as  a  (very) 
useful  side-effect,  Kecommended , 

Graham71 

GrahaiBj,  Clancy^  G,J,j,  and  DeVaney,  D.  B.  ;  A 
Software  Design  and  Evaluation  System;  Proceedings  of 
the  ACM/SIGOPS  Workshop  on  System  Performance 
Evaluation  (April  1971)  pp. 200-213. 

There  are  two  primary  drawbacks  to  modelling  as  a 
part  of  the  implementation  process.  First  is  the  need 
to  construct  the  model  separately  from  the  system, 
diverting  people  from  the  primary  objective.  Second  is 
the  problem  of  keeping  the  model  current  as  the  system 
primitives  are  re-defined, 

DBS  makes  use  of  a  single  language  to  describe  the 
object  system  at  all  levels  of  design  and 
implementation.  In  this  way  simulation  goes  hand-in- 
hand  with  design  and  the  performance  of  the  final 
system  may  be  accurately  estimated  before  full 
implementation;,  potentially  saving  a  costly  re-design. 

Graham73b  CH25,424  3*11 

Graham;,  R.M,;,  Clancy  Jr.,  G.J.,  and  Devaney,  D.B.;  A 
Software  Design  and  Evaluation  System;  Communications 
or  ACM;,  vol.16,  no, 2  (Feb.  1973)  pp. 110-116. 

The  DES  system  is  an  operating  system  writing 
system  implemented  in  a  superset  of  PL/1,  Procedures, 
data  items  and  hardware  characteristics  are  maintained 
in  d  data  set  that  aid  in  simulating  the  performance  of 
incompletely  written  subsystems.  Each  component  can  be 
evaluated  to  produce  a  graph  representation  of  the 
procedure^  information  on  external  references,  resource 
usage  and  interface  and  constraint  violations.  The 
Diethcdology  produces  a  probabilistically  collapsed 
graph  of  the  original  system  which  is  input  to  a 
general  purpose  simulator.  Unfortunately,  asynchronous 
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Lucas,  H.C.,  and  Presser,  L. ;  A  Method  of  So 
Evaluation:  the  Case  of  Language  Translators 

Computer  Journal,  vol.16,  no. 3  (Aug.  1973)  pp.22 

This  paper  presents  a  method  of  eval 
software,  in  particular,  language  translators, 
of  14  characteristics  for  quantitative  comparis 
language  translators  is  given.  The  design  of  syn 
benchmark  programs  to  evaluate  some  of 
characteristics  is  described.  In  the  sp 
evaluation  example  given,  the  evaluation  conclude 
WATFIV  is  superior  to  IBM  FORTHAN  G  or  H, 
installation  where  much  time  is  spent  debugging  - 
very  profound  result.  How  to  perform  an  eval 
along  similar  lines,  where  the  specifications  ar 
as  well-defined,  or  where  the  software  is  no 
finished,  debugged,  and  available  for  use,  or  wh 
decision  must  be  made  between  two  available  pr 
with  different  specifications,  is  not  clear  from 
paper. 
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Parnas,  D.L.,  and  Barringer,  J.A.;  SODAS  and  a 
Methodology  for  System  Design;  Proceedings  of  the  FJCC, 
vol. 31(1967)  pp. 449-474. 
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Nemeth'/I  Ch22,645  I^IO 

Nemeth,  A.G.,  and  Rovner,  P.D.;  User  Program 
Measurement  in  a  Time-Shared  Environment; 
Communications  of  the  ACM,  vol.14,  no. 10  (Oct.  1971) 

pp. 661-666. 

The  article  presents  a  method  used  on  the  TX-2 
computer  at  the  MIT  Lincoln  Laboratory  for  the 
measurement  of  time  usage  distribution,  number  of 
supervisor  program  requests,  size  of  request  blocks  and 
frequency  counts  of  user-specified  events.  It  is  a 
combined  software  and  hardware  system  that  allows 
interactive  measurement  of  program  performance  under 
user  control.  The  events  to  be  measured,  the  frequency 
of  sampling  these  events,  the  distribution  controlling 
any  random  variation  in  sampling  frequency,  the  segment 
of  the  program  to  be  measured  and  the  format  of  the 
output  are  all  user-controlled  in  this  system,  which 
has  been  used  to  debug  large  programs  found  to  have 
time  inefficiencies  not  susceptible  to  logical 
identification. 

Gotlieb70  7*9 

Gotliebj,  C.C.,  and  MacEwan,  G.H.;  System  Evaluation 
Tools;  in  Buxton^  and  Randell,  B.  (ed.). 
Software  Engineering  Techniques  i^9^Q)  pp. 93-99. 

Bard73  2*9 

Bard,  Y.;  Experimental  Evaluation  of  System 
Performance;  IBM  System  Journal,  vol,12,  no. 3  (1973) 
pp. 302-314. 


The  paper  reports  on  a  method  for  testing  system 
performance,  developed  to  be  used  as  part  of  an 
evolutionary  operation  technique  to  improve  systems. 

The  performance  of  different  features  of  the 
system  are  tested  by  using  rapid  on-line  switching,  as 
opposed  to  conventional  day-by-day  switching,  of  the 
various  versions.  This  technique  of  on-line  switching 
has  been  used  successfully  to  test  a  paging  replacement 
algorithm,  various  time-slicing  constants  and  the 
effect  of  assigned  priorities  on  the  user  in  a  time 
sharing  system. 

Arbuckle66  CR9,553  3*7 

Atbuckle,  R.A.;  Computer  Analysis  and  Thruput 
Evaluation;  Computers  and  Automation,  vol.15,,  no.  1 
(January  1966)  pp, 12-15,  19. 
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Arbackle  maintains  that  computer  efficiency  should 
be  measured  in  terms  of  thruput  (number  of  jobs 
completed  per  unit  time)  rather  than  raw  internal 
power.  He  elaborates  other  methods  of  evaluation 
(including  core  cycle  time,  add-time,  instruction  time, 
instruction  mix,  kernel  problems,  benchmark  problems) 
and  points  out  their  shortcomings.  Unfortunately, 
working  for  a  hardware  manufacturer,  Arbuckle  only 
considers  hardware  modifications  to  improve  efficiency. 

Arden69 


Arden,  B.W.,  and  Boettner,  D.;  Measurement  and 
Performance  of  a  Multiprogramming  System;  Proceedings 
ACM  Second  Symposium  on  Operating  Systems  Principles 
(Oct.  1969)  pp. 130-146. 

This  paper  opens  with  a  brief  description  of  the 
University  of  Michigan  Multi-Programming  System  (IJMMPS) 
and  MTS  in  order  to  lay  the  foundation  for  a  discussion 
of  software  measurement.  It  then  describes  two  basic 
types  of  measurement  (  (1)  processor  time  and  elapsed 
time  (2)  "microscopic"  recording  of  certain  events  over 
a  short  period  of  time)  and  how  they  may  be  applied  to 
large  systems  (in  particular  UMMPS) .  Finally  a  measure 
of  time  sharing  efficiency  (ideal  response  time  over 
actual  response  time)  is  introduced  and  several  tables 
and  graphs  are  presented  to  display  various  performance 
characteristics. 
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Bard,  Y, ;  CP-67  Measurement  a 
of  ACM/SIGOPS  Workshop  on  Sys 
(April  1971)  . 

Discusses  the  statis 
techniques  used  to  compare 
with  respect  to  throughput,  o 
is  interesting  for  several 
system  on  which  to  perform  re 
measurements.  Additionally, 
results  of  this  and  a  prior  s 
some  modules  with  dramatic  i 
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tical  and  measurement 
various  releases  of  CP-67 
verhead,  etc.  This  paper 
reasons.  CP-67  is  an  easy 
latively  interference-free 
the  application  of  the 
tudy  led  to  a  re-design  of 
mprovement  in  performance. 


Bard? 2 


Bard,  i. ,  and  buryanarayana,  K.?.;  On  the  structure  of 
CP-67  Overhead;  in  Freiberger,  W,  (ed. ) ,  Statistical 
Computer_Perf or mance_Eyaluation^  Academic  Press  (1972). 

Regression  analysis  lives  again  in  this  thrilling 
tale  from  the  annals  of  IBM's  history.  Still,  it's  a 
good  way  to  determine  actual  software  bottlenecks,  and 
those  concerned  with  producing  efficient  real-time 
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programs  should  probably  be  acquainted  with  the  uses  of 
the  technique. 

CampbelltoB  CH16,874 

Campbell,  D.J.,  and  Heffner,  W.J.;  Measurement  and 
Analysis  of  Large  Operating  Systems  During  System 
Development;  Proceedings  of  the  FJCC,  vol.33,  part  1 
(1968)  pp. 903-914. 

While  this  paper  touches  upon  simulation  ana  other 
methods  to  pre-evaluate  system  performance,  the  primary 
thrust  is  on  the  incorporation  of  on-line  measurement 
tools  into  the  evolving  system  so  that  performance  may 
be  monitored  and  improved  once  operation  begins..  The 
strategic  placement  of  measurement  hooks  requires  that 
the  critical  parameters  of  the  final  system  be 
identified  in  advance,  a  task  which  can  lead  to  better 
implementation  in  the  first  place. 

Cantr ell68 

Cantrell(^  and  Ellison,  A.L.;  Multiprogramming 

System  Performance  Measurement  and  Analysis; 
Proceedings  of  the  SJCC,  vol.  32  (1968)  pp. 213-222. 

Curaraiiig71  Ca23,205 

Gumming,  C.B.;  Monitoring  the  Operation  of  System 
Software;  Software  —  Practice  and  Experience,  vol.  1, 
no.  4  (1971)  pp. 383-389. 

Deniston69  CH18,278 

Deniston,  W.R.;  SPIE:  A  TSS/360  Software  Measurement 
Technique;  Proceedings  of  the  ACM  24th  National 
Conference  (1969)  pp. 229-245. 

Deu tsch72 
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of  IFIP  Congress 
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Fox67 
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Much  effort  has  been  directed  of 
improvement  of  problem-program  performa 
memory  systems.  This  paper  describes  a 
determining  the  memory-use  characteristic 
and  then,  through  a  combination  of  automa 
algorithms  and  heuristics,  rearranging 
paging  behavior,.  The  method  described, 
many,  is  practical,  in-use,  and 
(typically)  5  to  1  improvement. 

Kiffibleton72  Ci(23,879 

Kimbleton,  S.P,;  Performance  Evaluation  - 
Approach;  Proceedings  of  the  SJCC, 
pp.41 1-416. 
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Lucas71  CK23,420 

Lucas,  H.C.;  Pertor  iiiance  Evaluation  and  Monitoring; 
Computing  Surveys,  vol.3,  no. 3  (September  1971)  pp.79- 

91. 

Margolin72 

Margolin,  B.H.,  Parmelee,  R.P.,  and  Schatzoff,  M.; 
Analysis  of  Free  Storage  Algorithms;  in  Freiberger,  W. 

(ed.) ,  Statistical _ Computer _ Performance _ Evaluation^ 

Academic  Press  (1972). 

A  description  of  an  excellent  melding  of  system 
measurement,  statistical  techniques,  modelling  and 
experiment  design  which  resulted  in  a  substcintial 
improvement  in  the  CP-67  operating  system.  Highly 
recommended  to  those  interested  in  banging  existing 
software  into  shape. 

Miller 72 

Miller,  E.F.;  Bibliograpy  on  Techniques  of  Computer 
Perfoinance  Analysis;  Computer,  vol,5,  no. 5  (September/ 
October  1972)  pp. 39-47. 

Though  many  of  the  entries  in  this  bibliography 
are  system-oriented,  there  are  still  more  which  can 
provide  ideas  for  structuring  programs  in  an  attenpt  to 
improve  their  operating  efficiency. 

Pinke  rton69 

Pinkerton,  T.B.;  Performance  Monitoring  and  Systems 
Evaluation;  in  Naur,  P.,  and  Randell,  B.  (ed) , 
Software  Engineering  (1969)  pp. 200-203. 

Seaman69  CR18,985 

Seaman,  P.H.,  and  Soucy,  R.C.;  Simulating  Operating 
Systems;  IBM  Systems  Journal,  vol.8,  no. 4  (1969) 
pp. 264-279. 

Heider ma  n7  1 

Weiderman,  N.H.;  Synchronization  and  Simulation  in 
Operating  System  Construction;  Ph.D.  Thesis,  Cornell 
University,  Department  of  Computer  Science  (September 
1971)  . 

Description  of  an  operating  system  design 
methodology  which  proceeds  in  a  strict  top-down  order 
and  combines  simulation  with  implementation  to  verify 
system  structure  and  predict  object-system  performance. 
A  good  review  of  other  techniques  is  included;  chapters 
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three  and  tour  are  of  particular  interest.  For 
comparison  purposes,  see  Graham's  D.E.S.,  Parnas's 
SODAS  and  the  Zurcher  and  Randell  paper. 


TOPICS 

Evaluation: 

AlexanderVI,  Arbuckle66,  Cantrell68,  Cheatham72b, 
Cumraing71,  Gotlieb70,  Kay69,  Ki mble ton7 2,  Lucds73, 
Miller72,  8dndell71,  Wortiaan72; 

Modelling: 

Bard72,  Fox67,  Lassettre72,  Bargolin72; 

Simulation: 


Campbell68,  Grdhdra71,  Grdhdm73b, 
Seaman69,  Supuik71,  Weiderman71, 


Par nas67 , 
Zurcher68 ; 


Parnas69b, 


Monitoring : 


Atden69, 
Dakin73 , 
Neaeth7  1 , 


Bard71,  Bard73,  CampbellBS,  Cumining71, 
Deniston69,  Deatsch72,  Hatfield71,  Lucds71, 
Pinkerton69 ; 
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VIIo  Documentation 

Aiierbach72  2*15 

Auerbach;  Documentation  Aids;  Auerbach  Standard  EDP 
Reports;  Auerbach  Info,  Inc.,  no. 8  (11972). 

This  is  an  extensive  and  essentially  complete 
survey  of  documentation.  Various  uses  of  documentation 
during  project  planning,  implementation  and  maintenance 
are  described.  The  elements  of  documentation  (e.g., 
history  and  status^  glossaries^  program  description, 
equipment  and  software  environment)  are  enumerated  and 
justified.  Since  Auerbach  is  essentialy  a  software 
products  handbook,  the  main  focus  of  the  paper  is  on 
what  automatic  documentation  can  and  should  do  for  a 
program.  The  capabilities  or  text  and  comment 
processing,  intention  abstraction  and  graphical 
flowcharting  or  paragraphing  are  investigated  in 
relation  to  the  components  of  a  program.  The  component 
descriptions  discussed  are  functional  relations,  data 
bases,  files  and  tables. 

Mill370  CH19,422  1*14 

Mills,  H.  ;  Syntax  Directed  Documentation  for  )?L360; 
Coaiiunicat ions  of  the  ACM,  vol.ll,  no.  4  (April  1970) 

pp. 216-222, 


Mills  has  developed  an  interactive  system  that 
parses  a  PL360  program,  paragraphs  ir,  and 
interactively  interrogates  the  programsier  about  the 
intention  of  each  main  syntactic  construct.  This 
attempts  to  ensure  that  every  source  line  is  well 
documented.  The  programmer's  responses  are  kept  in  an 
online  program  aanagement  system.  This  system  can 
subsequently  be  asked  about  identifier  usage  and  the 
purpose  of  certain  classes  of  actions.  Primitive  text 
retrieval  from  the  documentation  given  a  keyword  may 
also  be  done.  This  system  is  essentially  experimental. 
However  it  does  point  the  way  to  future  automated 
docuraeEita t ion  systems. 

Selig69  1^11 

Selig,  F. ;  Documentation  Standards;  in  Naur,  P. ,  and 
Randell,  B.  (ed.).  Software  Engineering  (1969)  pp.209- 
211. 

Conrow70  5*10 


Conrow,  K„,  and  Smith,  R.G.;  NEATER2:  A  PL/I  Source 
Statement  Reformatter;  Communications  of  the  ACM 
voi.13,  no.  11  (1970)  pp. 669-675. 
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The  paper  describes  a  PL/I  p 
paragraphs  other  PL/I  programs  to  show 
structure.  The  authors  claim  this  helps 
that  it  makes  it  easier  for  the  programme 
the  program  does  not  conform  to  the 
intended.  In  addition  simple  syntact 
found  by  the  program  (e.y.,  missing  st 
The  use  of  the  ”goto'*  is  discouraged  as 
the  logical  structure.  An  option  w 
statements  to  collect  usage  statis 
available. 

Menkus70  Ch20,783 

Menkus,  B.;  Defining  Adequate  Systems 
Journal  of  Systems  Management,  vol. 
(December  1970)  pp. 16-21. 
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The  systems  discipline  which  emerged 
with  strong  foundations  in  logical  analys 
documentation  has  suffered  severely  from 
dazzle  of  computerization”.  This  pape 
importance  of  attention  to  detail  and 
standards  but  warns  against  redundancy 
and  the  proliferation  of  forms  and  pa 
types  and  functions  of  documentation  are 
effective  methods  are  presented  with 
checklist. 
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Walsh69  CR19,392  2*9 

Walsh,  D.  ;  A_Guide_t o_Sof  tware_ _ Dgcumen ta tion_i  McGraw- 

Hill,  N.Y.  (1969)  pp. 1-157. 

This  paper  is  a  detailed  guide  to  producing  step- 
by-step,  full  documentation  for  any  system.  The  user 
is,  in  effect,  stepped  through  the  production  of  a  full 
set  of  documentation.  However,  no  examples  are 
included,  which  detracts  somewhat  from  the  usefullness. 
Moreover,  there  is  no  discussion  of  the  methodology  or 
documentation,  nor  of  the  reasoning  behind  it.  Thus 
the  paper  can  be  considered  only  a  cookbook,  rather 
than  a  useful  paper  for  software  engineering. 

VanDuyn72  2*8 

Van  Duyn,  J.;  Documentation  Manual;  Auerbach, 

Philadelphia  (1972)  pp.  1-158. 
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The  author  does  not  feel  it  necessary  to  justify  the 
methods  presented,  since  they  are  taken  from  practices 
that  are  standard  and  widely  accepted  at  least  in  the 
commercial  programming  field. 

Pearson73  2*7 

Pearson,  K,M.;  Cataloguing  Computer  Software; 
Datamation,  vol.19,  no.  10  (October  1973)  pp. 87-91, 

This  article  discusses  the  present  methods  of 
cataloguing  systems  software,  and  argues  that  it  is 
inadequate.  Instead,  the  author  espouses  his  own 
system,  involving  complete  description  and  interfacing 
facilities.  In  parricular,  he  argues  that  the  name  of 
the  programmer  should  be  included,  since  a  knowledge  of 
the  programming  style  of  an  individual  can  give  a  good 
idea  of  the  probable  structure  of  the  program. 

Scowen7  1  3*6 

Scowen,  Allin,  D,  ,  Hillman,  A.D.,,  and  Shimell, 

SOAP  -  A  Program  which  Documents  and  Edits  ALGOL60 
Programs;  Computer  Journal,  vol,  14,  no. 2  (1971)  pD,133- 

135. 


This  paper  discusses  SOAP, 

ALGOL60  programs.  The  program 
doing  some  syntax  checking.  The 
option  of  replacing  any  token 
occurs  with  another  terminal, 
referred  to,  however,  is  only 
listing,  with  some  nice  features, 
then,  dees  not  really  do  any  documentation 
produces  bookkeeping  listings. 
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program  allows  the 
terminal  wherever  it 
The  documentation 
a  cross-reference 
The  paragrapher, 
but  merely 
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Goes,  G. ;  Documentation;  in  Bauer,  F.L.  (ed.). 

Advanced  Course  on  Software  Engineering,  Springer- 
Verlag,  New  York  (1973)  pp. 385-394. 

Meadow66  Cai3,305 


Keadow,  C.T.,  and  Waugn,  D.V.;  Computer 
Interrogation;  Proceedings  of  the  FJCC,  vcl. 
pp.3S''.-294. 


Assisted 
29  (1966) 


Ha tki ns73 


Watkins,  R.?.;  Towards  a  Theory  of  Documentation;  The 
Australian  Computer  Journal,  vol.5,  no. 2  (May  1973) 
pp . 57-61 . 
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hn  advance  is  made  toward  the  theory  or 
documentation  by  the  definition  of  inteiisional 
documentation,  extensional  documentation,  and  level  of 
detail.  This  provides  a  formal  statement  of  the 
structure  of  documentation.  The  statement  not  only 
matches  the  current  intuitive  concepts,  but  gives  a 
deeper  insight  into  the  reasons  foL  and  values  of  these 
structures. 


TOPICS 

Other  documentation  papers: 

Beffler69,  Brinch  Hansen73a,  Brophy70,  Fosdick72, 
Garwick61,  Habermann73,  Int.  Computers70,  Kay69, 
Kerpelman71,  naynard72,  nills73b,  Parnas72e,  Siismons72; 
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VIII.  Kiscellaneoas 


Cheathain72b  CR23,934  1^13 

Cheatham,  T.E,,  and  Wegbreit,  b.;  A  Laboratory  for  the 
Study  of  Automating  Programming;  Proceedings  of  the 
SJCC,  vol.  40  (1972)  pp.  11-21. 

Needhaffl70b  7*12 

Needham,  R.M.,  and  Aron,  J.D.;  Software  Engineering  and 
Computer  Science;  in  Buxton,  J.N.,  and  Handell, 
B.(ed.),  Software  Engineering  Techniques  (April  1970) 
pp.  113-114. 

Computer  science  aims  at  defining  general 
principles  underlying  the  design  and  application  of 
software  systems.  The  software  engineer  wants  to  make 
something  which  works;  where  working  includes 
satisfying  commitments  of  function,  cost,  delivery  ana 
robustness.  "Pending  major  theoretic  advances, 
software  engineering  should  concentrate  on  the 
development  of,  and  the  exchange  of  experience  about, 
practical  tools  such  as:  diagnostic  aids,  protected 
testing  facilities,  automatic  or  semi-automatic 
fallback,  aids  to  continuity  during  development,  etc.” 

Arden72  CH25,286 

Arden,  B.W.,  Flanigan,  L.K.,  and  Caller,  B.A..;  An 
Aavanced  System  Programming  Course;  Proceedings  of  IFIP 
Congress  71,  vol.  2  (1972)  pp. 15 10- 1514. 

Cor bin7  1 

Corbin,  K.,  Corwin,  W.,  Goodman,  B. ,  Hyde,  E, ,  Kramer, 
K.,  Herme,  E. ,  Wulf,  W. ;  A  Software  Laboratory- 
Preliminary  Report;  Car negie-Kellon  University, 
Department  of  Computer  Science,  no,  104  (1971). 

Darden70  CR20,d38 

Darden,  S.  and  Heller,  S. ;  Streamline  Your  Software 
Development;  Computer  Decisions,  vol. 2,  no. 10  (Oct. 
1970)  pp. 29-33. 

Donovari70 

Donovan,  J.J.;  Software  Engineering  -  An  Experiment  and 
a  Report;  IFIP  World  Conference  on  Computer 
Education  (1970) . 
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Maurer 70 


CR2  1,548 


Maurer,  W.;  Generalized  Interpretation  and  Compilation; 
in  Tou,  J,T.  (ed.),  Sof t ware_£niiineer  1113^.  vol.  1, 
Academic  Press,  N.Y.  (1970)  pp.  139-150. 

Parnas72a 

Parnas,  D.L.;  A  Course  on  Software  Engineering 
Techniques;  STGCSE  Bulletin,  vol.  4,  no.  1  (March 
1972)  pp.  154-159. 

Per lis69 

Perils,  A.J,;  Identifying  and  Developing  Cirricula  in 
Software  Engineering;  Proceedings  of  the  SJCC,  vol,  34 
(1969)  pp. 540-541. 

Shaw72  CR25,285 

Shaw,  A.W.  and  Weiderman,  N.H.;  A  Multiprogramming 
System  for  Education  and  Research;  Proceedings  of  IFIP 
Congress  71,  vol.  2  (1972)  pp. 1 505- 1 509. 

Tei tleman70 

Teitleman,  W. ;  Toward  a  Programming  Laboratory;  in 
Buxton,  J.N.,  and  Randell,  B.  (ed.).  Software 
Engineering  Techniques  (1970)  pp.  137-  149. 


TOPICS 

Education; 

Bauer73,  Buxton71,  Cons tantine68 ,  Corbin71,  Donovan70, 
Needhaffi70b,  Parnas72a,  Parnas72d,  Perlis69; 

Laboratories: 

Arden72,  Cheatham72b,  Corbin71,  Parnas72d,  Shaw72, 
Teitleman70; 
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